[Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

Guido van Rossum gvanrossum at gmail.com
Tue May 17 06:12:33 CEST 2005


[Jack Diederich]
> I prefer trichomomies over dichotomies, but whether single or double
> underscores are "the bad" or "the ugly" I'll leave to others.  In python
> double underscores can only mean "I don't handle this, my class does" or
> "I'm a C++ weenie, can I pretend this is private?"
>
> Excluding the "private" non-argument the only question is where it goes
> in the class hierarchy.  Is it a property you would normally associate
> with the instance, the class of an instance, or the class of a class (type).
> 
> To me it feels like a property of the instance.  The values are never
> shared by expections of the class so just make it a plain variable to remind
> other people of that too.

Can't tell if you're just trying to be funny, but that sounds like
nothing remotely like the rule I use in my head to decide whether to
make something a system attribute or a regular attribute.

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.)

Unfortunately I can't quite decide whether either rule applies in the
case of exceptions. I think it's totally plausible to say "all
exceptions derive from Throwable, which predefines the following
attributes: traceback, cause". OTOH making them system attributes is
more backwards compatible.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list