[Python-Dev] Re: [python-committers] [RELEASE] Python 3.11.0a3 is available

2021-12-09 Thread Victor Stinner
Yeah, another Python 3.11 alpha release! The asyncore, asynchat and smtpd modules are back into Python 3.11! They were removed but the removal has been reverted to respect the PEP 387 process: have two Python versions (3.10 and 3.11) emitting a DeprecationWarning. In general, I strongly advice yo

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

2021-12-09 Thread Petr Viktorin
On 08. 12. 21 18:06, Eric Snow wrote: On Wed, Dec 8, 2021 at 2:23 AM Petr Viktorin wrote: That really depends on what function we'd want to remove. There are usually alternatives to deleting things, but the options depend on the function. If we run out of other options we can make the function

[Python-Dev] Re: [RELEASE] Python 3.11.0a3 is available

2021-12-09 Thread Mark Shannon
On 08/12/2021 11:51 pm, Pablo Galindo Salgado wrote: * The [Faster Cpython Project](https://github.com/faster-cpython ) is already yielding some exciting results: this version of CPython 3.11 is ~12% faster on the geometric mean of the [PyPerformance benc

[Python-Dev] Re: [RELEASE] Python 3.11.0a3 is available

2021-12-09 Thread Pablo Galindo Salgado
Thanks, Mark for the catch! I have updated it in the release page and all announcements where I can edit the text :) On Thu, 9 Dec 2021 at 12:34, Mark Shannon wrote: > > > On 08/12/2021 11:51 pm, Pablo Galindo Salgado wrote: > > > * The [Faster Cpython Project](https://github.com/faster-cpython

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

2021-12-09 Thread Eric Snow
On Thu, Dec 9, 2021 at 1:56 AM Petr Viktorin wrote: > It's possible to remove them just like _PyObject_GC_Malloc was removed, > but check that it was unusable (e.g. not called from public macros) in > all versions of Python from 3.2 up to now. That's what I expected. Thanks. > Could you check i

[Python-Dev] Should isinstance call __getattribute__?

2021-12-09 Thread Steven D'Aprano
I'm looking for some guidance on a bug report involving isinstance and __getattribute__` please. The issue is that if your class overloads `__getattribute__`, calling isinstance on an instance will call the overloaded `__getattribute__` method when looking up `__class__`, potentially causing is

[Python-Dev] Re: Should isinstance call __getattribute__?

2021-12-09 Thread Ronald Oussoren via Python-Dev
> On 9 Dec 2021, at 16:41, Steven D'Aprano wrote: > > I'm looking for some guidance on a bug report involving isinstance and > __getattribute__` please. > > The issue is that if your class overloads `__getattribute__`, calling > isinstance on an instance will call the overloaded `__getattrib

[Python-Dev] Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Eric Snow
(replying to https://mail.python.org/archives/list/python-dev@python.org/message/OJ65FPCJ2NVUFNZDXVNK5DU3R3JGLL3J/) On Wed, Dec 8, 2021 at 10:06 AM Eric Snow wrote: > What about the various symbols listed in Misc/stable_abi.txt that were > accidentally added to the limited API? Can we move towa

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Petr Viktorin
I'll not get back to CPython until Tuesday, but I'll add a quick note for now. It's a bit blunt for lack of time; please don't be offended. If the code is the authoritative source of truth, we need a proper parser to extract the information. But we can't really use an existing parser (e.g. we need

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Guido van Rossum
Maybe we could start by having the tool regenerate the file and verifying that it produces the same results? Then in the future we keep the file in the repo so changes to it can be tracked separately, but we run the tool as part of CI to make sure that its output still matches. This is what we do f

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Christian Heimes
On 09/12/2021 19.26, Petr Viktorin wrote: I'll not get back to CPython until Tuesday, but I'll add a quick note for now. It's a bit blunt for lack of time; please don't be offended. If the code is the authoritative source of truth, we need a proper parser to extract the information. But we can't

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Jim J. Jewett
Christian Heimes wrote: > On 09/12/2021 19.26, Petr Viktorin wrote: > > If the code is the authoritative source of truth, we need a proper > > parser to extract the information. ... unfortunately I don't trust it > > enough to let it define the API. Bugs in the parser could result in > > the API

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

2021-12-09 Thread Eric Snow
On Thu, Dec 9, 2021, 11:26 Petr Viktorin wrote: > I'll not get back to CPython until Tuesday, but I'll add a quick note > for now. It's a bit blunt for lack of time; please don't be offended. > Not at all. :) The tooling is a secondary concern to my point. Mostly, I wish the declarations in th