The ConfigParser module defines a variety of custom exceptions, many of 
which take more than one argument (e.g., InterpolationError, 
NoOptionError, etc.).   However, none of these exceptions properly set 
the .args attribute.   For example, shouldn't NoOptionError be defined 
as follows:

class NoOptionError(Error):
    def __init__(self,option,section):
        Error.__init__(self,"No option %r in section: %r" %
                       (option,section))
        self.option = option
        self.section = section
        self.args = (option,section)      #!! Added this line

This is kind of a minor point, but the missing args means that these 
exceptions don't work properly with programs that need to do fancy kinds 
of exception processing (i.e., catching errors and reraising them in a 
different context or process).

I can't speak for Python 3.0, but it's my understanding that .args 
should always be set to the exception arguments.

Don't ask how I came across this---it was the source of a really bizarre 
bug in something I was playing around with.

Sound argument. I've prepared a patch for Py3k that adds `args` for all exceptions. Unit tests were modified as to check whether the `args` are set correctly (which helped finding a couple of flaky assertions in the tests themselves :)).

Brett, the code change is trivial. Tests aren't complicated as well. Should this change also be ported to py27-maint?

Tests failed after patching test file, all passed after patching the code on Windows against 3.2.  The patch looks simple and clean so I don't see why it can't be committed.  As this is a behaviour issue the code should also be backported.

Thanks, Mark. Should I do the backporting or do you have some technology/process for this?

I can do the backport as well if it doesn't require SVN commit access. I would need some help because it would be my first backport :)

Łukasz, no problem.  It would be my first backport too! :) I think that it's best left to the committers as they've well used to doing things like this.

Committed revision 83150.

Still needs backporting to 3.1, 2.7 and possibly even 2.6.

Patch doesn't apply cleanly to 3.1 or earlier. As it is *arguably* a new feature rather than a bugfix I'm closing the issue.

I certainly wouldn't argue against someone else backporting though...

New changeset 8e091e36fc80 by Łukasz Langa in branch '2.7':
Fixes #4686. Reverts redundant picklability code from r74544.
http://hg.python.org/cpython/rev/8e091e36fc80