[EMAIL PROTECTED] wrote: > Aahz> Taking a look at __slots__ is fine as long as you don't actually > Aahz> use them. > > Gabriel> Why? > http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=2#f4ac2dfde32b16fd > > Skip
The subject of __slots__ really seems to get some people's dander up, to the extent where the heat/light ratio in the discussion becomes uncomfortably high. Right here, we have Skip referring to a post by Aahz, where Aahz says that Guido says that slots are bad mojo, without anybody ever giving concrete examples about why this may be the case. The only assertion that was made explicitly enough to be testable came about in a followup to Aahz's original post, only AFTER someone asked what the side-effects associated with __slots__ were. Aahz responded: > The main one is that inheritance becomes difficult to nearly-impossible. But this statement is either wrong or incomplete. Classes can certainly inherit from other classes which define __slots__, and this statement doesn't describe the problems well enough for any reader to figure out whether those problems directly affect him or not. The only problem I personally know of is that the __slots__ aren't inherited, but if you just view slots as a storage optimization, that's not a terrible thing. Also, with duck-typing, inheritance isn't necessarily all that important for many classes of classes, even if you take the limited view that all programming is object-oriented. I can certainly imagine that __slots__ do not give anywhere near the benefit that was envisioned when they were first implemented, and I can well believe that the implementation was, in retrospect, a "mistake". It may well be that, in hindsight, the cost/benefit ratio was too high to warrant having implemented them. I can also believe that many people may see __slots__ and think "Aha! This is how I implement type-checking!" This is typically considered unPythonic, so obviously when someone posts about how their type-checking wasn't properly inherited when they subclassed an object, a lot of heavy signing and gnashing of teeth will ensue. So, since __slots__ shouldn't have been implemented (and since they may not be implemented in Python 3000?) and since a lot of question about __slots__ are in reference to problems they weren't intended to solve in any case, it makes sense that people get testy about the whole thing, but is that any reason to _always_ assert that an existing languange feature should _never_ be used (and never back it up with relevant concrete examples about the associated problems)? My own experience with __slots__ has been quite positive, when I wanted to create millions of instances of the same well-defined small object. When the choices boil down to using __slots__ or dropping to C or Pyrex, I'll take __slots__ every time, whether or not that is Pythonically correct. Now, if someone has a well-written technical answer about how I might get bitten doing this, I would love to see it (but "__slots__ might be removed later because it was a mistake, so you'll have to rewrite your performance code in Pyrex anyway, so you wasted the 5 minutes you spent adding __slots__ to some of your classes two years ago" doesn't count). If anybody ever wrote such a useful answer, I missed it, so please give me a pointer to it! For a similar, probably better-written, perspective, check out: http://www.dalkescientific.com/writings/diary/archive/2006/03/19/class_instantiation_performance.html Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
