Possible wart in PEP-0253
Nick Mathewson
ZnickZm at alum.mit.edu
Mon Sep 17 16:43:57 EDT 2001
Hello all. In playing around with PEP-0253 behavior, I think I've
found a possible wart. If it isn't a wart, it's at least a hole in
the documentation.
I went to write the following test code:
class Foo(tuple):
def __setattr(self, attr, val):
raise AttributeError("You can't set attributes here")
def __init__(self):
# Here's the standard workaround.
self.__dict__['parrot'] = 'no more'
Of course, when I called Foo(), I got a TypeError, because __dict__ is
set to None until object.__setattr__ is called. There's no way to
modify __dict__ except by calling object.__setattr__, so to make my
code work, I needed to use
object.__setattr__(self, 'parrot', 'no more') instead.
My suggestion is this: would it be possible to relax the
assignment-to-__dict__ rule at least so far that if __dict__ is None,
you can assign a new empty __dict__? Or add to a declaration
(__init_dict__?) that makes the metaclass always materialize an empty
__dict__ when __new__ is called?
Otherwise, from now on, the generic way to spell
"self.__dict__['foo'] = bar"
will be instead
"object.__setattr__(self,'foo',bar)".
Except that: for classes that don't extend types, the first spelling
will continue to work. And for classes that *do* extend types, the
first spelling will work in all cases but the first.
Though I can quite gladly accept that this is as intended, it
certainly took me a while to figure it out for myself. :)
So, what ought I do? Submit this to sourceforge? To the FAQ? Or just
accept that PEP-0253 is heavy business, and try to come to terms with
it on my own? :)
But-quite-possibly-this-isn't-so-confusing-as-I'm-making-it-sound-ly Y'rs,
--
Nick Mathewson <Z nick Z m at alum dot mit dot edu>
Remove Z's to respond. No spam.
More information about the Python-list
mailing list