Possible wart in PEP-0253

[Nick Mathewson]

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.