[Guido van Rossum] > > My rule has more to do with who "owns" the namespace on the one hand, > > and with "magic" behavior caused (or indicated) by the presence of the > > attribute on the other. Class or instance is irrelevant; that most > > magic attributes live on classes or modules is just because those are > > places where most of the magic is concentrated. > > > > __init__ in a class is a system attribute because it has a magic > > meaning (invoked automatically on instantiation). __file__ and > > __name__ in a module (and __module__ and __name__ in a class!) are > > system attributes because they are "imposing" on the user's use of the > > namespace. (Note: next was a mistake; it should have been __next__ > > because of the "magic" rule.)
[Aahz] > >From my POV, part of the reasoning should be the extent to which the > attribute is intended to be publicly accessible -- part of the primary > documented interface. __init__ is magic, fine. But __name__ isn't part > of the primary use for a class, whereas these new exception attributes > will be part of the public interface for exceptions, just like the > methods for the Queue class. (I'm using Queue in specific because it's > intended to be subclassed.) I dunno. Would you find __doc__ not part of the primary, documented interface of classes? Or __bases__? The Queue class is irrelevant because the VM doesn't know about it; *almost* all system atribute are referenced by the VM (or by the compiler) at some point(*). The reverse is not true, BTW -- many built-in objects (e.g. tracebacks, code and function objects) have non-system attributes. If this were Python 3000, I'd definitely make the traceback and cause non-system attributes. Given we're retrofitting, I'm less sure; surely some user-defined exceptions have cause and/or traceback attributes already. (*) I'd say metadata like __version__ is the exception; it's a system attribute because it's metadata, and because it lives in a crowded namespace, and because it was retrofitted as a convention. -- --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