On 11/29/05, Nick Coghlan <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
