On Mon, May 11, 2020 at 08:59:42PM +0100, Barry Scott wrote:
> The \0 can never be part of a valid file in Unix, macOS or Windows.
There are a few file systems which accept NULs in file names, such as
HFS and HFS+ and (I think) Joliet.
HFS+ volumes include a special special directory called the
On 5/13/20 2:22 AM, Stephen J. Turnbull wrote:
> MRAB writes:
> > On 2020-05-11 09:21, Chris Angelico wrote:
> > > On Mon, May 11, 2020 at 6:09 PM Steve Barnes
> wrote:
>
> > >> Actually, in the case of the “wrong quotes” it puts the pointer
> > >> under the character before the space charact
On Wed, 13 May 2020 20:52:38 +1000
Steven D'Aprano wrote:
>
> I don't know how complete HFS+ support is on Linux or Windows, but in
> principle any OS that supports HFS+ or (maybe) Joliet could have files
> with NULs.
>
> Remember that NULs may be legal next time you are stress testing your
>
Wow - a lot going on this thread -
despite what to do seemingly really obvious:
of course showing which character triggered the error
along with a proper plain English phrase is enough.
The Fortran anecdote in the beginning of the thread is a
false analogy, since the program _will_ _not_ run with
On Wed, May 13, 2020 at 11:13 PM Antoine Pitrou wrote:
>
> On Wed, 13 May 2020 20:52:38 +1000
> Steven D'Aprano wrote:
> >
> > I don't know how complete HFS+ support is on Linux or Windows, but in
> > principle any OS that supports HFS+ or (maybe) Joliet could have files
> > with NULs.
> >
> > Re
How adverse would you guys feel about a change to the way asserts are handled
so that they are not recoverable? Asserts could latch on to the first failed
assert and always throw an AssertionError on subsequent assert statements.
Another way would be for subsequent asserts to turn off after the
On 13/05/2020 15:22, [email protected] wrote:
How adverse would you guys feel about a change to the way asserts are
handled so that they are not recoverable? Asserts could latch on to
the first failed assert and always throw an AssertionError on
subsequent assert statements. Another
On 5/13/2020 10:40 AM, Rhodri James wrote:
On 13/05/2020 15:22, [email protected] wrote:
How adverse would you guys feel about a change to the way asserts are
handled so that they are not recoverable? Asserts could latch on to
the first failed assert and always throw an AssertionEr
On 5/13/20, Antoine Pitrou wrote:
>
> If you know of a system function which accepts filenames with embedded
> NULs (which probably means it also takes the filename length as a
> separate parameter), I'd be curious to know about it.
Windows is layered over the base NT system, which uses counted s
I'm working with developers that have decided to use asserts every time they
want to throw an exception. I feel that their should be something that
dissuades this behavior in the language design. This could be making asserts
not recoverable, making it so you can't stop assert failures from print
On Thu, May 14, 2020 at 2:20 AM wrote:
>
> I'm working with developers that have decided to use asserts every time they
> want to throw an exception. I feel that their should be something that
> dissuades this behavior in the language design. This could be making asserts
> not recoverable, maki
That's what I did on my first day :D
Setting up my dev environment for the first time, the 'run this to make sure it
is set up' script was failing. After walking the debugger through several 'this
should not happen' oddities, the developer that was helping me eventually
figured out I was running
On May 12, 2020, at 23:29, Stephen J. Turnbull
wrote:
>
> Andrew Barnert writes:
>>> On May 10, 2020, at 22:36, Stephen J. Turnbull
>>> wrote:
>>>
>>> Andrew Barnert via Python-ideas writes:
>>>
A lot of people get this confused. I think the problem is that we
don’t have a word f
I'm sorry, but it is just unreasonable to expect us to consider a random
backwards incompatible language change just because you can't get your
developers to follow a reasonable coding guideline.
On Wed, May 13, 2020 at 10:30 AM Chris .
wrote:
> That's what I did on my first day :D
> Setting up
On 13/05/2020 17:20, [email protected] wrote:
I'm working with developers that have decided to use asserts every
time they want to throw an exception. I feel that their should be
something that dissuades this behavior in the language design.
I'm sorry, but I think the correct resp
On May 13, 2020, at 05:31, Richard Damon wrote:
>
> On 5/13/20 2:22 AM, Stephen J. Turnbull wrote:
>> MRAB writes:
>>>
>>> This isn't a parsing problem as such. I am not an expert on the
>>> parser, but what's going is something like this: the parser
>>> (tokenizer) sees the character "=" and
It took me a good while to "get" the distinction between an itertor and an
iterable, and I still misuse those terms sometimes.
Maybe because iterable is an awkward word (that my spell checked doesn't
recognize)?
But it's also because there is a clear definition for "Iterator" in Python,
bu the te
On 5/13/20 2:03 PM, Rhodri James wrote:
> On 13/05/2020 17:20, [email protected] wrote:
>> I'm working with developers that have decided to use asserts every
>> time they want to throw an exception. I feel that their should be
>> something that dissuades this behavior in the language
On Wed, May 13, 2020 at 05:28:20PM -, Chris . wrote:
> That's what I did on my first day :D Setting up my dev environment for
> the first time, the 'run this to make sure it is set up' script was
> failing. After walking the debugger through several 'this should not
> happen' oddities, the
On 13May2020 16:20, [email protected]
wrote:
I'm working with developers that have decided to use asserts every time they
want to throw an exception.
Since asserts are disabled when the optimiser is activated, I'd say
these devs don't speak Python.
Also, AssertionErrors are
On May 13, 2020, at 12:40, Christopher Barker wrote:
I hope you don’t mind, but I’m going to take your reply out of order to get the
most important stuff first, in case anyone else is still reading. :)
>> Back to the Sequence View idea, I need to write this up properly, but I'm
>> thinking som
On 14/05/20 8:55 am, Richard Damon wrote:
On 5/13/20 2:03 PM, Rhodri James wrote:
I'm sorry, but I think the correct response is to give them a spanking
in code review. I certainly wouldn't pass any code that actually
relied on assert doing anything.
My thought was he just needs to add that
On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
> On May 13, 2020, at 12:40, Christopher Barker wrote:
>
> I hope you don’t mind, but I’m going to take your reply out of order to
> get the most important stuff first, in case anyone else is still reading. :)
>
And I'm going to keep this re
OK, now for:
On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
> Now onto the stuff that probably nobody else cares about:This is your mail
> agent being a pain again. You’re the one who said that, I quoted you saying
> it, and now you’re agreeing with yourself.
>
Of COURSE I agree ith myse
> On May 13, 2020, at 20:32, Christopher Barker wrote:
>
>>> On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
>> On May 13, 2020, at 12:40, Christopher Barker wrote:
>>
Back to the Sequence View idea, I need to write this up properly, but I'm
thinking something like:
>>>
>>>
On May 13, 2020, at 20:49, Christopher Barker wrote:
>
> OK, now for:
>
>> On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
>
>> But that’s the wrong generalization. Because sets also work the same way,
>> and they aren’t Sequences. Nor are dict views, or many of the other kinds of
>> t
26 matches
Mail list logo
