[Python-Dev] Possible undefined behavior on creating a method named "__dict__"
On Wed, 11 Apr 2018 at 05:09 Steven D'Aprano <steve at pearwood.info> 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
> 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
> > 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.
> > 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.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...