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
It's finally time to schedule the last releases in Python 2's life. There will be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18.
Python 2.7.17 release candidate 1 will happen on October 5th followed by the final release on October 19th.
I'm going to time Python 2.7.18 to coincide with PyCon 2020 in April, so attendees can enjoy some collective catharsis. We'll still say January 1st is the official EOL date.
Thanks to Sumana Harihareswara, there's now a FAQ about the Python 2 sunset on the website: https://www.python.org/doc/sunset-python-2/
I think that PEP 573 is ready to be accepted, to greatly improve the state
of extension modules in CPython 3.9.
It has come a long way since the original proposal and went through several
iterations and discussions by various interested people, effectively
reducing its scope quite a bit. So this is the last call for comments on
the latest version of the PEP, before I will pronounce on it. Please keep
the discussion in this thread.
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue.
A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely).
And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any).
If you have an opinion please weight in on the issue.
As of 3.7, dict objects are guaranteed to maintain insertion order. But
set objects make no such guarantee, and AFAIK in practice they don't
maintain insertion order either. Should they?
I do have a use case for this. In one project I maintain a "ready" list
of jobs; I need to iterate over it, but I also want fast lookup because
I soemtimes remove jobs when they're subsequently marked "not ready".
The existing set object would work fine here, except that it doesn't
maintain insertion order. That means multiple runs of the program with
the same inputs may result in running jobs in different orders, and this
instability makes debugging more difficult. I've therefore switched
from a set to a dict with all keys mapped to None, which provides all
the set-like functionality I need.
ISTM that all the reasons why dicts should maintain insertion order also
apply to sets, and so I think we should probably do this. Your thoughts?
p.s. My dim recollection is that the original set object was a hacked-up
copy of the dict object removing the ability to store values. So
there's some precedent for dicts and sets behaving similarly. (Note:
non-pejorative use of "hacked-up" here, that was a fine way to start.)
First - best wishes all for a happy and healthy 2020!
As my nickname implies - my primary means to contribute to Python is
with regard to AIX. One of the things I recently came across is
Misc/README.AIX which was last updated sometime between 2010 and 2014. I
am thinking a facelift is in order. Assuming 2010-2011 as the original
date - much has changed and many of the comments are no longer accurate.
Before saying so, I would like to check here that - having all tests
pass on the 3.8 bot implies that there are no outstanding issues. As to
the historical issues in the current document - these could either be
deleted, or a short text describing when they were resolved (e.g.,
Python 3.7, or just resolved, but noone knows exactly how or when -
whether it was a Python change, or a platform (AIX) change.
What I see as being more relevant is the description re: how to build
Python for AIX - for the "do it youself"-ers.
So, besides the direct question re: what to say about the old "known
issues" and whether there are no known issues aka, no issues identified
via the standard tests - I would appreciate feedback on what is
considered appropriate - anno 2020 - for any Misc/README.platform text.
Additionally, I am willing to work on other areas of the standard
documentation where it is either needed or considered appropriate for
platform specific details and/or examples.
This is not something I would try to get done in a single PR, Instead I
am thinking a single -longer term- issue - and multiple PR's to work
through corrections and additions during 2020. Focus on Python 3.9 and
beyond yet where appropriate backlevel to Python 3.8 or even 3.7.
I've finally updated PEP 558 and it's reference implementation based
on Nathaniel's feedback back in May.
The latest version of the PEP can now be found at
https://www.python.org/dev/peps/pep-0558/, and I've created a
discussion thread on Discourse:
The latest version implements Nathaniel's "independent snapshot"
proposal, and I like how that has turned out. The one thing that
changed from the May discussion thread is that the refcount semantics
of PyEval_GetLocals() (it returns a borrowed reference) meant that it
had to keep the old behaviour of returning a reference to the internal
dynamically updated shared "snapshot" at function scope, with a new
API, PyEval_GetPyLocals(), providing the C equivalent of the locals()
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia