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 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__.

> 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