[Python-3000] removing exception .args (original) (raw)

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