[Python-3000] removing exception .args

Guido van Rossum guido at python.org
Sat Jul 21 17:31:13 CEST 2007


On 7/21/07, Georg Brandl <g.brandl at gmx.net> wrote:
> Andrew Dalke schrieb:
> > Posting here a expansion of a short discussion I had
> > after Guido's keynote at EuroPython.  In this email
> > I propose eliminating the ".args" attribute from the
> > Exception type.  It's not useful, and supporting it
> > correctly is complicated enough that it's often not
> > supported correctly
> >
> >
> >
> > In Python 2 the base Exception class works like this
> >
> >  >>> x = Exception("spam", "was", "here")
> >  >>> x[0]
> > 'spam'
> >  >>> x.args
> > ('spam', 'was', 'here')
> >  >>>
> >
> > In Py3K the [0] index lookup disappears.  This is a
> > good thing.  Positional lookup like this is rarely useful.
> >
> > The .args attribute remains.  I don't see the need for
> > it and propose that it be removed in Py3K.
>
> Hm, I always found it useful to just do
>
> class MyCustomError(Exception):
>      pass
>
> and give it arbitrary arguments to it without writing __init__
> method stuff that I can access from outside.

Right. Also, the fact that there is no *guarantee* that e.args
contains *all* the arguments passed to the constructor doesn't mean
that e.args isn't useful. It's useful for many standard exceptions. I
also happen to think that it's well-defined: it is whatever is passed
to Exception.__init__(), whether called directly or from an overriding
__init__() method.

Given the amount of code that currently uses it, I think removing it
would also be a major undertaking, as we would have to invent names
for everything that's currently accessed via e.args[i]. (I know
there's a lot of code that uses it, because converting the stdlib from
e[i] to e.args[i] was a major pain.)

So -1 on removing e.args. I'd be okay with a recommendation not to
rely on it and to define explicitly named attributes for everything
one cares for.

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


More information about the Python-3000 mailing list