Message97051
Everything I've read about __slots__, seen w/ them, etc, they're
effectively just a change in the underlying allocation- yes they can
limit the attributes, but that's about it.
Specifically, for general attribute access/mangling, best I can tell,
they're *supposed* to be exactly equivalent when manipulating the
object- the only difference being the backing store.
That said, delattr against slotted objects vs non slotted differs in a
rather buggy way- even worse, the behaviour differs on slotted classes
dependant on if you're delattr'ing a slotted attr or a nonslotted-
consider the following code.
class nonslotted(object):
pass
class slotted(object):
__slots__ = ("monkeys",)
try:
ns = nonslotted()
assert not hasattr(ns, 'monkeys')
del ns.monkeys
raise AssertionError("this is unreachable")
except AttributeError:
pass
try:
s = slotted()
assert not hasattr(s, 'monkeys')
del s.monkeys
print "slotting causes delattr to not throw an AttributeError"
# and now for the kicker
del s.some_attr_that_is_not_slotted
except AttributeError:
print "so... delattr results in AttributeError on a non-slotted attr,
but throws no AttributeError on a slotted attr..."
I'm guessing this isn't intentional/desired?
Confirmed on py2.6/py3.1 also; that said, I'd assume it affects all
versions of python that support __slots__... |
|
Date |
User |
Action |
Args |
2009-12-30 18:46:49 | ferringb | set | recipients:
+ ferringb |
2009-12-30 18:46:49 | ferringb | set | messageid: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za> |
2009-12-30 18:46:47 | ferringb | link | issue7604 messages |
2009-12-30 18:46:47 | ferringb | create | |
|