[Python-Dev] Replacing __slots__ with addmembers()

[Tim Peters]

[M.-A. Lemburg]
> ...
> True, but I'm also thinking about writing new code in Python
> which uses these features and there I don't see the stability
> of the API just yet (but would really like them to stabilize
> *before* 2.2 moves out the door and even if this means waiting
> until after Christmas ;-).

I tried to explain before that time isn't linear <wink>:  "after Christmas"
probably means "next spring at earliest", and we just aren't going to let
that happen.

I can only suggest you pretend we didn't release the new features, then, in
any aspect which appears unstable -- you're not required to use them.  While
new ways to spell __slots__ and property() and staticmethod() and
classmethod() and super may get invented later, the 2.2 ways won't go away.
So that's focusing on the wrong things.  The set of things that *may* break
appears impossible to characterize.  For example, exactly how conflicts in
multiple inheritance get resolved, or exactly when an override of
__getitem__ in a subclass of dict will get invoked (e.g., currently not for
.update()), or that referencing an uninitialized __slot__ attr currently
returns None instead of raising NameError, or that e.g.

>>> class myint(int):
...     def __init__(self, val):
...         int.__init__(val * 2)
...
>>> i = myint(3)
>>> i
3
>>>

without warning, etc.  I don't know how to characterize these:  they have
nothing in common, apart from being arguable.  But *all* language behavior
is arguable, so that's not a clue either -- what's different in this case is
that Guido is still open to arguing about the new stuff.  That means it's
all experimental, to some degree.