[Python-Dev] [Python 2.2 BUG] pickle/cPickle does not find __slots__
Michael McLay
mclay@nist.gov
Fri, 15 Feb 2002 14:19:19 -0500
On Friday 15 February 2002 12:57 pm, john coppola wrote:
> Another issue I have with __slots__ is that there
> exists better notation to do the same thing. And part
> of python is to maintain a clean coding style. Why not
> introduce new a keyword into the language so
> "static attribute sets" are created like so:
>
> class Foo(object):
> attribute a
> attribute b
> attribute c
Guido suggested several alternative syntaxes during his presentation on
developers day at the Python conference. His slides are online from
python.org. He used the word "slot" instead of "attribute". Both names have
advantanges. He question the use of the term slot and was looking for an
appropriate substitute. It has the advantage of being short and easy to
type. Using the term "attribute" would be more descriptive. I find it very
long to type and somewhat visually distracting.
>
> Perhaps this syntax could be expanded further to
> include strict typing:
>
> class Foo(object):
> attribute a is str
> attribute b is float
> attribute c is int
I suggested a method for adding optional static typing to slots and submitted
a patch[1] last November. My patch eliminated the special __slots__ member
and replaced it with a special method to a class called addmember() that
could be used to add slot definitions to a class. A docstring, an
optional type, and a default value could be specified as parameters in the
addmembers() method. If a type, or tuple of types was defined the
tp_descr_set call in C would first check the type of the object being
assigned to the member name using the isinstance() builtin. If isinstance
failed an exception would be triggered.
While my approach was patterened after the property() builtin, the Python
Labs crowd didn't like the notation and rejected the patch. (I don't think it
helped that the feature freeze was about to start and Guido was out of
paternity leave.) Here was example of how the addmember() method worked:
>>> class B(object):
"""class B's docstring
"""
a = addmember(types=int, default=56, doc="a docstring")
b = addmember(types=int, doc="b's docstring")
c = addmember(types=(int,float), default=5.0, doc="c docstring")
d = addmember(types=(str,float), default="ham", doc="d docstring")
>>> b = B()
>>> b.a
56
>>> b.d
'ham'
[1]http://sourceforge.net/tracker/index.php?func=detail&aid=480562&group_id=5470&atid=305470
I think most everyone would agree that adding optional static typing could
enable some interesting optimizations, but not everyone at the conference was
supportive of the encrouchment of static typing on their favorite
dynamiically typed language.
Greg Ward presented a proposed syntax for optional static typing at the end
of the optimization sesssion on developer's day. Greg had made a
presentation on Grouch, his postprocessing type checker for ZODB, during the
lightning talks. The proposed syntax for optional static typing was a meld of
Guido's proposed new syntax for slots, my addmembers() work, and Greg's
Grouch. Guido wasn't keen on the docstring notation, but otherwise seemed to
be receptive of the syntax and the idea of adding optional static typing.
Here is what Greg presented:
# ======================================================================
# WHAT IF...
#
# Grouch's type syntax were integrated into Python?
class Thing:
slot name : string
"The name of the thing"
class Animal (Thing):
slot num_legs : int = 4
"Number of legs this animal has"
slot furry : boolean = true
"Does this animal have full-body fur?"
class Vegetable (Thing):
# hypothetical constraint (is this type info?)
slot colour : string oneof ("red", "green", "blue")
"Colour of this vegetable's external surface"
class Mineral (Thing):
slot atoms : [(atom:Atom, n:int)]
"""Characterize the proportion of elements in this
mineral's crystal lattice: each tuple records the
relative count of that atom in the lattice."""
# possible constraints on this attribute:
# n > 0
# atom in AtomSet (collection of all atoms)
# how to code these? do we even *want* syntax
# for arbitrary constraints? or just require that
# you code a set_atoms() method? (or a property
# modifier, or something)
>>> class B(object):
"""Docstring of class B
"""
slot a: int = 56
"""a docstring
"""
precondition:
if b > 3:
default=3
slot b: int
"""Docstring of b
"""
slot c: int | float = 5.0
"""Docstring of attribute c
"""
slot d: str | float = "spam"
"""Docstring of d
"""
postcondition:
if self.b = 42.0
>>> b = B()
>>> b.a