Re: [Python-Dev] Are undocumented functions part of the stable ABI?
On 2018-04-10 13:49, Nick Coghlan wrote: If it's only a semantic level change in the way the macro gets expanded, then whether or not it needs an ABI version guard gets judged on a case-by-case basis, and in this particular case, my view would be that developers should be able to write extensions using the stable ABI that accept function subclasses on 3.8+, without having to *require* the use of 3.8+ to import their module. I don't really get this paragraph, but in any case I decided to *not* change PyCFunction_Check in PEP 575. It doesn't seem worth the trouble as this macro is probably not often used anyway. Also, it's hard to guess what it should be replaced with: why would extensions be calling PyCFunction_Check()? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible undefined behavior on creating a method named "__dict__"
I just came across a code snippet that would define a method with the "__dict__" name - like in: class A: def __dict__(self): return () The resulting class's instances can be assigned dynamic attributes as usual, but one can never acess its actual local variables through instance.__dict__ - the method is retrieved instead. Calling "vars" will also fail on objects of this class. This behavior is weird, and I believe is actually a side-effect of implementation details on CPython. I am not sure whether it shoud just: 1 - be left as is - whoever reuses __dict__ as a method had it coming 2 - document CPythn behavior 3 - file that as a bug to disallow __dict__ override in class declaration 4 - file that as a bug to not-create class __dict__ when one is explictly created in Python code (the same that happens when one have "__slots__". I have the feeling that (1) is just good - but then, I am at least posting this e-mail here. Similar weird things go when one creates a method named "__class__", and possible other names. (I just checked that pypy3 mimics the behavior) js -><- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible undefined behavior on creating a method named "__dict__"
On Wed, Apr 11, 2018 at 08:21:01AM -0300, Joao S. O. Bueno wrote: > I just came across a code snippet that > would define a method with the "__dict__" name - like in: > > class A: > def __dict__(self): > return () That's a strange thing to do, but I don't think it ought to be illegal. Consenting adults and all that. > The resulting class's instances can be assigned > dynamic attributes as usual, but one can never acess > its actual local variables through instance.__dict__ - > the method is retrieved instead. Yes, I believe that is expected behaviour for attribute access since the descriptor protocol was added. Methods take priority over data attributes, if I recall correctly. > Calling "vars" will also fail on objects of this class. I consider that a pseudo-bug. I can't call it an actual bug, because vars() doesn't document that it will work even when __dict__ is shadowed in this way, but I think it should. So its a bug against a future feature :-) Attribute access still works correctly even with such a shadow: py> class W: ... def __dict__(self): ... return () ... py> obj = W() py> obj.spam = 1 py> obj.spam 1 so there is still an instance dict somewhere inside the instance, and the C attribute-access machinary can access it. I think vars() should be able to do the same. (I'm not saying this in order to encourage people to shadow __dict__.) > This behavior is weird, and I believe is actually a side-effect > of implementation details on CPython. Its certain a weird thing to do, but I don't believe it is an implementation detail. Apart from the behaviour of vars(), I think the behaviour here all follows from the documented behaviour of the descriptor protocol. > I am not sure whether it shoud just: > 1 - be left as is - whoever reuses __dict__ as a method had it coming > 2 - document CPythn behavior > 3 - file that as a bug to disallow __dict__ override in class declaration > 4 - file that as a bug to not-create class __dict__ when one is explictly > created in Python code (the same that happens when one have "__slots__". > > I have the feeling that (1) is just good - but then, I am at least > posting this e-mail here. I agree that (1) is the best, but vars() ought to work even in the precence of a method shadowing __dict__. > Similar weird things go when one creates a method named "__class__", > and possible other names. type(instance) still works correctly when instance.__class__ is shadowed by a method. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reminder: 2018 Python Language Summit signups close next week
The deadline is a week from today, April 18th 2018. Original
announcement below.
--
It’s that time again: time to start thinking about the Python Language
Summit! The 2018 summit will be held on Wednesday, May 9, from 10am to
4pm, at the Huntington Convention Center in Cleveland, Ohio, USA. Your
befezzled and befuddled hosts Barry and Larry will once more be behind
the big desk in front.
The summit’s purpose is to disseminate information and spark
conversation among core Python developers. It’s our yearly opportunity
to get together for an in-person discussion, to review interesting
developments of the previous year and hash out where we’re going next.
And we have lots to talk about! 3.7 is in beta, and we've all
collectively started work on 3.8 too.
As before, we’re using Google Forms to collect signups. Signups are
open now; the deadline to sign up is Wednesday April 18th, 2018 (AoE).
Please do us a favor and sign up sooner rather than later. The signup
form is simpler this year--I bet most people can be done in less than
two minutes!
One difference from last year: there are now *two* forms. The first
form is for signing up to attend (the "Request For Invitation" form),
and the second form is for proposing a talk. Please note: if you want to
present, you still need to fill out the Request For Invitation form
too. (Yes, it's more complicated this way, sorry. But having both on
the same form kind of enforced a one-to-one mapping, and it's really a
many-to-many mapping: one person might propose multiple talks, and one
talk might have multiple presenters. Overall this should be less
complicated.)
You can find links to *both* forms on the official Python Language
Summit 2018 page:
https://us.pycon.org/2018/events/language-summit/
A few notes:
* There will be lightning talks! Signups will only be available
during the Language Summit itself.
* You don’t need to be registered for PyCon in order to attend the summit!
* We’ll have badge ribbons for Language Summit participants, which
we’ll hand out at the summit room in the morning.
* We're inviting Jake Edge from Linux Weekly News to attend the summit
and provide press coverage again. Jake’s done a phenomenal job of
covering the last few summits, providing valuable information not
just for summit attendees, but also for the Python community at
large. Jake’s coverage goes a long way toward demystifying the
summit, while remaining respectful of confidential information
that’s deemed “off the record” ahead of time by participants.
One big final note (please read this!):
When using Google Forms, you /can/ edit your responses later! When
you fill out the form and hit Submit, the submission complete page
(the one that says "Thanks for playing!") will have a link on it
labeled "Edit your response". BOOKMARK THIS LINK! You can use this
link at /any time/ to edit your response, up to the point that
signups close on April 18th. Keep in mind, you'll need to bookmark
each response independently: once for signing up to attend ("Request
For Invitation"), and once for each talk proposal you submit.
Again, /please/ be sure to save this bookmark yourself--we don't
know how to find the link for you later if you don't save it.
We hope to see you at the summit!
[BL]arry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible undefined behavior on creating a method named "__dict__"
On Wed, 11 Apr 2018 at 05:09 Steven D'Aprano wrote: > On Wed, Apr 11, 2018 at 08:21:01AM -0300, Joao S. O. Bueno wrote: > > I just came across a code snippet that > > would define a method with the "__dict__" name - like in: > > > > class A: > > def __dict__(self): > > return () > > That's a strange thing to do, but I don't think it ought to be illegal. > Consenting adults and all that. > > > > The resulting class's instances can be assigned > > dynamic attributes as usual, but one can never acess > > its actual local variables through instance.__dict__ - > > the method is retrieved instead. > > Yes, I believe that is expected behaviour for attribute access since the > descriptor protocol was added. Methods take priority over data > attributes, if I recall correctly. > Yep, they do. > > > > Calling "vars" will also fail on objects of this class. > > I consider that a pseudo-bug. I can't call it an actual bug, because > vars() doesn't document that it will work even when __dict__ is shadowed > in this way, but I think it should. So its a bug against a future > feature :-) > > Attribute access still works correctly even with such a shadow: > > py> class W: > ... def __dict__(self): > ... return () > ... > py> obj = W() > py> obj.spam = 1 > py> obj.spam > 1 > > so there is still an instance dict somewhere inside the instance, and > the C attribute-access machinary can access it. I think vars() should be > able to do the same. > > (I'm not saying this in order to encourage people to shadow __dict__.) > > > > This behavior is weird, and I believe is actually a side-effect > > of implementation details on CPython. > > Its certain a weird thing to do, but I don't believe it is an > implementation detail. Apart from the behaviour of vars(), I think the > behaviour here all follows from the documented behaviour of the > descriptor protocol. > > > > I am not sure whether it should just: > > 1 - be left as is - whoever reuses __dict__ as a method had it coming > > 2 - document CPython behavior > > 3 - file that as a bug to disallow __dict__ override in class declaration > > 4 - file that as a bug to not-create class __dict__ when one is explictly > > created in Python code (the same that happens when one have > "__slots__". > > > > I have the feeling that (1) is just good - but then, I am at least > > posting this e-mail here. > > I agree that (1) is the best, but vars() ought to work even in the > presence of a method shadowing __dict__. > I say option 1 as well. -Brett > > > > Similar weird things go when one creates a method named "__class__", > > and possible other names. > > type(instance) still works correctly when instance.__class__ is shadowed > by a method. > > > -- > Steve > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible undefined behavior on creating a method named "__dict__"
On Wed, Apr 11, 2018 at 5:08 AM, Steven D'Aprano wrote: > On Wed, Apr 11, 2018 at 08:21:01AM -0300, Joao S. O. Bueno wrote: > > I just came across a code snippet that > > would define a method with the "__dict__" name - like in: > > > > class A: > > def __dict__(self): > > return () > > That's a strange thing to do, but I don't think it ought to be illegal. > Consenting adults and all that. Python's guarantee in this case goes no further than that it promises not to crash in C code. There's a rule in the language reference that says that all __dunder__ names are reserved for the implementation and they should only be used according to the documentation. So, indeed, it's not illegal, but you are not guaranteed that anything works, either. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
