[Python-Dev] PEP 352: Required Superclass for Exceptions

[Brett Cannon]

On 10/28/05, Guido van Rossum <guido at python.org> wrote:
> On 10/28/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Brett Cannon wrote:
> > > Anyway, as soon as the cron job posts the PEP to the web site (already
> > > checked into the new svn repository) have a read and start expounding
> > > about how wonderful it is and that there is no qualms with it
> > > whatsoever.  =)
> >
> > You mean aside from the implementation of __getitem__ being broken in
> > BaseException*? ;)
>
> Are you clairvoyant?! The cronjob wass broken due to the SVN
> transition and the file wasn't on the site yet. (Now fixed BTW.) Oh,
> and here's the URL just in case:
> http://www.python.org/peps/pep-0352.html
>

Nick got the python-checkins email and then read the PEP from the
repository (or at least that is what I assume since that is how Neal
managed to catch the PEP literally in under 5 minutes after checkin).

> > Aside from that, I actually do have one real problem and one observation.
> >
> > The problem: The value of ex.args
> >
> >    The PEP as written significantly changes the semantics of ex.args - instead
> > of being an empty tuple when no arguments are provided, it is instead a
> > singleton tuple containing the empty string.
> >
> >    A backwards compatible definition of BaseException.__init__ would be:
> >
> >      def __init__(self, *args):
> >          self.args = args
> >          self.message = '' if not args else args[0]
>
> But does anyone care? As long as args exists and is a tuple, does it
> matter that it doesn't match the argument list when the latter was
> empty? IMO the protocol mostly says that ex.args exists and is a tuple
> -- the values in there can't be relied upon in pre-2.5-Python.
> Exceptions that have specific information should store it in a
> different place, not in ex.args.
>

Looking at http://docs.python.org/lib/module-exceptions.html , it
looks like Guido is right.  All it ever says is that it is a tuple and
that any passed-in arguments go into 'args'; nothing about its default
value if no arguments are passed in.

But I personally have no qualms changing it if people want it, so -0
from me on making it more backwards-compatible.

> > The observation: The value of ex.message
> >
> >    Under PEP 352 the concept of allowing "return x" to be used in a generator
> > to mean "raise StopIteration(x)" would actually align quite well. A bare
> > "return", however, would need to be changed to translate to "raise
> > StopIteration(None)" rather than its current "raise StopIteration" in order to
> > get the correct value (None) into ex.message.
>
> Since ex.message is new, how can you say that it should have the value
> None? IMO the whole idea is that ex.message should always be a string
> going forward (although I'm not going to add a typecheck to enforce
> this).
>

My feeling exactly on 'message'.

-Brett