I only care about getting this right when there is a reasonable chance that a class is being used as an object. For example, at the sprint we ran into this with the __format__ special method, when someone discovered that format(object, "") raised a weird error rather than returning str(object), which was due to the default __format__ method defined on the object class. It's important that you can format *anything*, so we fixed this right away.
OTOH for the with-statement, the object passed to it is always specially constructed to work in this context, and passing something random like a type object just isn't a reasonable use case. As long as you get *some* kind of error (and you do, usually complaining about the arg count) I'm okay. --Guido On 9/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Georg Brandl wrote: > > Thomas Heller schrieb: > > > >> IIUC, in py3k, classic classes do not exist any longer, so the > >> __metaclass__ line > >> has no effect anyway. Is this behaviour intended? > > > > It is another incarnation of special methods being looked up on the class, > > not the instance. This was always the behavior with new-style classes, see > > the thread at > > > > http://mail.python.org/pipermail/python-3000/2007-March/006261.html > > > > for a previous discussion. > > > > I think we should tackle this issue now and make sure the decided resolution > > is consistently applied throughout Python. > > This issue came up when implementing PEP 343 as well - because the with > statement is just syntactic sugar without any dedicated opcodes, > __enter__/__exit__ are accessed via a conventional attribute lookup > opcode. So unlike the special methods that use a C-level slot in the > type object, these two operations *can* be affected by instance > attributes and __getattr__. > > However, Guido did say at the time that he was OK with the effect of > instance attributes on special method lookups being formally undefined > and implementation dependent. I wasn't too worried either way - mucking > with special methods outside the scope of 'provide this on your class to > support operation X' has long been a pretty dubious exercise. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --------------------------------------------------------------- > http://www.boredomandlaziness.org > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
