On 11/29/05, Nick Coghlan <ncoghlan at gmail.com> wrote: > The bit that more concerns me is the behavioural discrepancy that comes from > having a piece of syntax that looks in the instance dictionary. No other > Python syntax is affected by the instance attributes - if the object doesn't > have the right type, you're out of luck. I'm not sure I buy that. Surely there are plenty of other places that call PyObject_GetAttr(). Classic classes still let you put an __add__ attribute in the instance dict to make it addable (though admittedly this is a weak argument since it'll go away in Py3k). > Sticking an __iter__ method on an instance doesn't turn an object into an > iterator, but with the current semantics, doing the same thing with > __context__ *will* give you a manageable context. This is all a very gray area. Before Python 2.2 most of the built-in operations *did* call PyObject_GetAttr(). I added the slots mostly as a speed-up, and the change in semantics was a side-effect of that. And I'm still not sure why you care -- apart from the error case, it's not going to affect anybody's code -- you should never use __xyzzy__ names except as documented since their undocumented use can change. (So yes I'm keeping the door open for turning __context__ into a slot later.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4