[Python-Dev] Re: __dunder__ = None

It actually is documented as being supported here: https://docs.python.org/3.10/reference/datamodel.html#id2, and as mentioned there __iter__(), __reversed__() and __contains__() also have special support so they avoid trying to fallback to __getitem__ etc. Also some discussion at https://githu

[Python-Dev] Re: __dunder__ = None

01.05.22 13:02, Spencer Brown пише: It actually is documented as being supported here: https://docs.python.org/3.10/reference/datamodel.html#id2 , and as mentioned there __iter__(), __reversed__() and __contains__() also have special s

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

On Sat, 30 Apr 2022, 3:02 am Guido van Rossum, wrote: > > I think picking "semi-stable" would be giving in to the OCD nerd in all of > us. :-) While perhaps technically less precise, "unstable" is the catchy > name with the right association. (And yes, we should keep it stable within > bugfix rel

[Python-Dev] Re: __dunder__ = None

On 01/05/2022 06:20, Serhiy Storchaka wrote: The question is how to interpret value None: * Always raise TypeError (with changed message)? This is what happen currently when you set the method to None, this is the most compatible option. * Always raise an error, but allow to change it to more

[Python-Dev] Re: __dunder__ = None

Non should behave as closely as possible to it not being defined at all. So return NotImplemented. On Sun, May 1, 2022 at 09:53 Patrick Reader <_...@pxeger.com> wrote: > On 01/05/2022 06:20, Serhiy Storchaka wrote: > > The question is how to interpret value None: > > > > * Always raise TypeError

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

FWIW, I'm in agreement.  My "forward class" proposal(s) were me trying to shine a light to find a way forward; I'm in no way adamant that we go that direction.  If we can make 649 palatable without introducing forward declarations for classes, that's great!  If in the future we discover more

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

Can someone state what's currently unpalatable about 649? It seemed to address the forward-referencing issues, certainly all of the cases I was expecting to encounter. On Sun, 2022-05-01 at 15:35 -0600, Larry Hastings wrote: > > FWIW, I'm in agreement.  My "forward class" proposal(s) were me > tr

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On 5/1/22 15:44, Paul Bryan wrote: Can someone state what's currently unpalatable about 649? It seemed to address the forward-referencing issues, certainly all of the cases I was expecting to encounter. Carl's talk was excellent here; it would be lovely if he would chime in and reply.  Here

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

Hi Paul, On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote: > > Can someone state what's currently unpalatable about 649? It seemed to > address the forward-referencing issues, certainly all of the cases I was > expecting to encounter. Broadly speaking I think there are 3-4 issues to resolve as

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

Thanks, Carl and Larry for the explanations. On Sun, 2022-05-01 at 16:13 -0600, Carl Meyer wrote: > Hi Paul, > > On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote: > > > > Can someone state what's currently unpalatable about 649? It seemed > > to address the forward-referencing issues, certainly

[Python-Dev] Re: __dunder__ = None

01.05.22 19:32, Guido van Rossum пише: Non should behave as closely as possible to it not being defined at all. So return NotImplemented. But, as was noted by Spencer Brown, it is not how it works for __iter__(), __reversed__() and __contains__() (which have a special path for producing expli