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.
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
For some reason I can't log into the bug tracker with Google.
I just get the error message:
An error has occurred
A problem was encountered processing your request.
The tracker maintainers have been notified of the problem.
Whether I'm logged in or out of Google, or using a private tab, it makes
Anyone else having problems?
I've been poking around the thread state API and error/exception
handling, and there's something missing I'd like to see happening.
The only way to retrieve the current exception is via sys.excinfo or
PyErr_GetExcInfo in C. However, the issue is that they don't take a
PyThreadState as argument, but use _PyThreadState_GET() to retrieve the
That makes it impossible to retrieve the exception information for a
different thread than the one calling the function.
In order to retrieve the exception from *any* PyThreadState, the caller
has to use _PyErr_GetTopmostException which takes a PyThreadState as
argument — though that function is private and therefore not documented
or usable in an external module (in theory at least).
Should we make _PyErr_GetTopmostException public, or implement something
different to retrieve the top most exception from a PyThreadState?
# Free Software hacker