[Python-Dev] PEP 352: Required Superclass for Exceptions
Guido van Rossum
guido at python.org
Fri Oct 28 17:22:09 CEST 2005
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:
> 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
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.
> 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
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev