zahlman at gmail
May 14, 2012, 10:15 AM
Post #17 of 17
On Sat, May 12, 2012 at 9:10 AM, Ethan Furman <ethan [at] stoneleaf> wrote:
Re: Dealing with the __str__ method in classes with lots of attributes
[In reply to]
> Firstly, __slots__ is a tuple.
I object: conceptually, the "slots" of a class are set in stone, but
the `__slots__` attribute of a class object is just an attribute, and
any iterable (as long as it yields valid identifier names) can be used
when the `__slots__` magic is invoked in the class definition. FWIW,
all the ordinary examples I've seen use a list, although a tuple
arguably makes more sense.
>>> class Evil(object):
... __slots__ = ('a%s' % a for a in range(10))
<generator object <genexpr> at 0x01EDFAA8>
 # the generator was consumed by the metaclass during class creation
[.'__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__has
h__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__rep
r__', '__setattr__', '__sizeof__', '__slots__', '__str__', '__subclasshook__', '
a0', 'a1', 'a2', 'a3', 'a4', 'a5', 'a6', 'a7', 'a8', 'a9'] # yep, the
expected attributes are there, and can be set.
>>> Evil.__slots__ = 42
# no exception
> Secondly, this is bad advice. __slots__ is there as a memory optimization
> for classes that will have thousands of instances and do not need the
> ability to have arbitrary attributes added after creation.
I did explicitly indicate the latter part.
> __slots__ is an
> advanced feature, and as such is easier to get wrong. It is *not* there to
> make __str__ nor __repr__ easier to write.
Of course not, but it seems to me that it serves well in this particular case.
>>>> class Test1(object):
> ... __slots__ = ('item', 'size')
> ... desc = 'class-only attribute'
>>>> t1 = Test1()
>>>> t1.desc = 'read-only attribute' # fails because 'desc' is
> # not in __slots__
Well, sure; expecting to modify a class attribute via an instance is a
bit naughty anyway.
>>>> print t1.item # fails because 'item' was
> # not set
Well, yes, that's what `__init__` is for; the same line would fail
without `__slots__` and for the same reason. Arguably, this is a
gotcha for people coming from C-like languages who are expecting
`__slots__` to make the class behave as if it had a defined layout,
but there isn't actually any more work involved here.
>>>> class Test2(Test1):
> ... def __init__(self, price):
> ... self.price = price
>>>> t2 = Test2(7.99) # __slots__ not defined in
> # subclass, optimizations lost
Well, yes, but we aren't using it for the optimizations here!
But I see your point; explicit is better than implicit, and our
explicit purpose here is to have an explicit list of the attributes
we're interested in for __str__/__repr__ - which could be any other
named class attribute, without magic associated with it. That said,
`__slots__` is as close to a canonical listing of instance-specific
attributes as we have (`dir()` clearly won't cut it, as we don't want
methods or other class-specific stuff).