In Python 2.5 `0or` was accepted by the Python parser. It became an
error in 2.6 because "0o" became recognizing as an incomplete octal
number. `1or` still is accepted.
On other hand, `1if 2else 3` is accepted despites the fact that "2e" can
be recognized as an incomplete floating point number. In this case the
tokenizer pushes "e" back and returns "2".
Shouldn't it do the same with "0o"? It is possible to make `0or` be
parseable again. Python implementation is able to tokenize this example:
$ echo '0or' | ./python -m tokenize
1,0-1,1: NUMBER '0'
1,1-1,3: NAME 'or'
1,3-1,4: OP '['
1,4-1,5: OP ']'
1,5-1,6: NEWLINE '\n'
2,0-2,0: ENDMARKER ''
On other hand, all these examples look weird. There is an assymmetry:
`1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
visually the boundary between a number and the following identifier or
keyword, especially if numbers can contain letters ("b", "e", "j", "o",
"x") and underscores, and identifiers can contain digits. On both sides
of the boundary can be letters, digits, and underscores.
I propose to change the Python syntax by adding a requirement that there
should be a whitespace or delimiter between a numeric literal and the
webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
If one goes to httWhps://www.python.org/downloads
<https://www.python.org/downloads> from a Windows browser, the default
download URL is for the 32-bit installer instead of the 64-bit one.
I wonder why is this still the case?
Shouldn't we encourage new Windows users (who may not even know the
distinction between the two architectures) to use the 64-bit version of
Python, since most likely they can?
If this is not the correct forum for this, please let me know where I can
direct my question/feature request, thanks.
I have for sometime maintained the Python bindings to the LZ4
compression library[0, 1]:
I am wondering if there is interest in having these bindings move to
the standard library to sit alongside the gzip, lzma etc bindings?
Obviously the code would need to be modified to fit the coding
I'm following the guidelines  and asking here first before
committing any work to this endeavour, but if folks think this would
be a useful addition, I would be willing to put in the hours to create
a PR and continued maintenance. Would welcome any thoughts.
> Date: Sun, 18 Nov 2018 22:32:35 +1000
> From: Nick Coghlan <ncoghlan(a)gmail.com>
> To: "Steven D'Aprano" <steve(a)pearwood.info>
> Cc: python-dev <python-dev(a)python.org>
> Subject: Re: [Python-Dev] Need discussion for a PR about memory and
[ munch background ]
> Chris's initial suggestion was to use "license number" or "social
> security number" (i.e. numbers governments assign to people), but I'm
> thinking a better comparison might be to vehicle registration numbers,
> since that analogy can be extended to the type and value
> characteristics in a fairly straightforward way:
> - the object identity is like the registration number or license plate
> (unique within the particular system of registering vehicles, but not
> unique across systems, and may sometimes be transferred to a new
> vehicle after the old one is destroyed)
> - the object type is like the make and model (e.g. a 2007 Toyota
> Corolla Ascent Sedan)
> - the object value is a specific car (e.g. "that white Corolla over
> there with 89000 km on the odometer")
> On the other hand, we're talking about the language reference here,
> not the tutorial, and understanding memory addressing seems like a
> reasonable assumed pre-requisite in that context.
"Handle" has been used since the 1980s among Macintosh and
Win32 programmers as "unique identifier of some object but isn't
the memory address". The usage within those APIs seems to
match what's being proposed for the new Python C API, in that
programmers used functions to ask "what type are you?" "what
value do you have?" but couldn't, or at least shouldn't, rely on
actual memory layout.
I suggest that for the language reference, use the license plate
or registration analogy to introduce "handle" and after that use
handle throughout. It's short, distinctive, and either will match
up with what the programmer already knows or won't clash if
or when they encounter handles elsewhere.
Steve Dower wrote:
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible with the low level API". The promise of "faster in
> the future" needs to be justified (and I think there's plenty of
> assume that we can do it).
It's hard to discuss this in the abstract without knowing how big the
breakage between each version is going to be.
But for the scientific ecosystem this sounds a bit like a potential
Python-4.0 breakage, which was universally rejected (so far).
In the extreme case I can imagine people staying on 3.7.
But it really depends on the nature of the changes.
I've had a PR open for nearly 3 months now with no review at:
I know everyone is overextended so normally I wouldn't fuss about it.
But I would still like to remain committed to providing better Cygwin
(and to a lesser extent, personally, MinGW) support in CPython. I
have had a buildbot chugging along rather uselessly due to the blocker
issue that the above PR fixes:
Only when the above issue is fixed will it be possible to get some
semi-useful builds and test runs on this buildbot.
The issue that is fixed is really a general bug, it just happens to
only affect builds on those platforms that implement a POSIX layer on
top of Windows. Specifically, modules that are built into the
libpython DLL are not linked properly. This is a regression that was
introduced by https://bugs.python.org/issue30860
The fix I've proposed is simple and undisruptive on unaffected platforms.
Thanks for having a look!