[Python-Dev] Replacing __slots__ with addmembers()

[Tim Peters]

[Michael McLay]
> I hope Python Labs doesn't rush Python 2.2 out early just to meet an
> artificial schedule.

Given the effort that goes into making them up, there's nothing artificial
about them <wink>.

> MAL's concerns about cluttering Python with several variations for
> spelling the same kind of feature is shared by me.

It seemed to me MAL was worried about something else, namely not having to
redo the guts of his provisions for user subclassing of sundry mx objects
(coded in C).

> I'm sure other long time users of Python would rather wait a few weeks
> to get something with fewer new warts.

I don't expect that's a realistic tradeoff.  While I'm sure Guido could make
excellent progress cleaning it all up given "a few weeks" with nothing else
on his plate, the latter isn't going to happen -- in reality it's going to
stretch over months, accompanied by much debate.  Given holiday schedules
and other commitments, if we don't do the December release as planned, I
expect 2.2 would slip beyond the Python Conference at best.  We don't want
that.

> Not all of these changes have the same level of impact on day to day
> programming. The __metatype__ and super() feature will be used far
> less than __slots__.

This will vary by programmer.

> Spelling __slots__ in a more pythonic manner now will eliminate having
> lots of ugly code being supported forever.

Where?  Inside Python?

> Tim suggested that the type checking feature might be enough to get the
> patch rejected.  For the moment let's assume I had not added that
> feature.  The patch does still makes adding member_descriptors more
> consistent with the syntax used to add properties.  There is consistency
> in usage with
>
>   property(fget, fset, doc)
>   addmember(default, doc)

I don't accept that's a Good Thing, though -- there's nothing notably
Pythonic about the spelling of properties now either, and indeed it all
looks very Lispish ("everything's a function application, and everything
looks like everything else").  At least "__slots__" doesn't look like
"property()" -- there's a visual clue that they're not the same thing.  Note
too that your property example is wrong:  you've passed a docstring in the
fdel method's position.  This is a symptom of strained spelling.

> Adding the default capability to adding a member is important because
> it will eliminate a very common initialization pattern.  Instead of
> writing:
>
> class B(object):
>   __slots__ = ['a','b']
>   def __init__(self,a=1,b="cats and dogs"):
>       self.a=a
>       self.b=b
>
> The addmember() feature reduces this to an easy to read:
>
> class B(object):
>   a = addmember(default=1, doc="the ever popular a attribute")
>   b = addmember(default="cats and dogs", doc="the b docstring")

Sorry, to my eye that's hard to read, and I bet a doughnut Guido will dream
up something better when he feels the time is right.  IOW, IMO the
suggestion is itself another wart.  I agree something's wrong with the
current semantics:  if you reference an uninitialized __slot__ vrbl now you
don't get NameError.

> This also allows docstrings to be added to the attributes, a feature
> that isn't possible with the current __slots__ spelling.

Neither with non-slot attributes.  Is not adding docstring ability to one
specific flavor of attribute, but not others, also a wart?

> The type checking feature can easily be removed.  I hope this doesn't
> happen.  This feature replaces another very common design pattern. While
> dynamic typing is very powerful, there are many occasions when data is
> required to be of a specific type.  For instance, engineering data
> exchange standards are filled with type checking requirements.
> Spacecraft crash into Mars for a lack of good checks.  This is not only
> embarrassing, it's expensive.

This is the province of the Types SIG, and adding one typecheck gimmick to
one isolated feature would be a wart too.

> Examples of type checking in Python are described in:
>  - http://mail.python.org/pipermail/python-dev/2001-October/017852.html

Among many other places, like, say, the Types SIG <wink>.

> The approach to adding this capability using addmember() is very
> pythonic. It is completely unintrusive to anyone who doesn't need it
> and it is very easy to use for those occasions when you must use it.

Write a PEP.  The issues deserve consideration, and more than we can make
time for before 2.2.  If Guido thinks otherwise he'll speak up.