[Python-Dev] New class/type features (Replacing __slots__ with addmembers())

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [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.

Why not ? Who's pushing us ? AFAIK, there's no marketing team
with a hammer out there forcing us to publish on a fixed date :-)

Hey, these new features were once proclaimed as the Grand
Unification to be announced in Python 3k... this step
is a very important one in Python's development. Self-imposed
deadlines should not get in the way of the design 
process. Well, IMHO, at least.

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

I know... but you know as well as I do that people will start
using these features right away -- "experimental" features have
a tradition in Python of not being experimental in the usual sense
of being subject to change in future releases.

People basically start experimenting and then assume that their
results will remain valid for years to come and shout out loud
if they don't.

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

That's what meant with the above note about "experimental" 
features in Python.

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

True, and that's why I would like to see a simple list of 
features which will be safe to use in Python 2.2 and which do 
expose a stable API. Something like:

* you can subclass from types and extend them, but not override 
  existing methods or attributes
* __specialmethods__ except __init__ are not guaranteed to
  work the same way as they do for instances
etc.

Or add a disclaimer like this to the prominent announcements, 
web-pages, etc.:
"""
Extending types in Python 2.2 is possible to some extent, 
but currently only provided for experimentation purposes
and to get more experience with the overall design. The design
will become stable in Python 2.3.
"""

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/