[Python-ideas] [Python-Dev] OSError.errno => exception hierarchy?

Guido van Rossum guido at python.org
Thu Apr 2 19:37:27 CEST 2009

[Moving to python-ideas]

On Thu, Apr 2, 2009 at 9:12 AM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> 2009/4/2 Guido van Rossum <guido at python.org>
>> On 4/2/09, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
>> > Apologies if this has already been discussed.
>> >
>> > I was expecting that by now, python 3.0,

Note, these words are pretty offensive (or perhaps
passive-aggressive). How would you respond if some Perl hacker said "I
was expecting that by now, Python 3.0, Python would have dropped the
whitespace bug."

>> > the following code:
>> >
>> >             # clean the target dir
>> >             import errno
>> >             try:
>> >                 shutil.rmtree(trace_output_path)
>> >             except OSError, ex:
>> >                 if ex.errno not in [errno.ENOENT]:
>> >                     raise
>> >
>> > Would have become something simpler, like this:
>> >
>> >             # clean the target dir
>> >             try:
>> >                 shutil.rmtree(trace_output_path)
>> >             except OSErrorNoEntry:       # or maybe os.ErrorNoEntry
>> >                 pass
>> >
>> > Apparently no one has bothered yet

Again, offensive words -- makes you sound like you are so much smarter than us.

>> > to turn OSError + errno into a hierarchy
>> > of OSError subclasses, as it should.  What's the problem, no will to do
>> > it or no manpower?

Again poor choice of words. Note the leading question: you don't even
consider the possibility that it's a bad idea. Compare "When did you
stop beating your wife?"

>> Sounds like a bad idea. There are hundreds of errno values. I don't
>> want to have hundreds of new exceptions -- especially not since not
>> all are defined on each platform.
> We already have the hundreds of errno values defined in the errno module.
> It is just a matter of turning the integers that we already have into
> exception subclasses of OSError.  My idea would be to only create exceptions
> for the errors listed in the module 'errno', and use a generic OSError for
> the rest of them.

This would cause more platform problems than we already have. Consider
an errno (EWIN, mapped to OSWinError in your proposal) that exists
only on Windows, and another (ELIN, OSLinError) that exists only on
Linux. Now suppose you have to catch both of them. If you write your
code like this:

  except OSWinError:
  except OSLinError:

then on Linux, if OSLinError is raised, the "except OSWinError:"
clause will raise a NameError because that exception isn't defined,
and you'll never reach the "except OSLinError:" clause. If you reverse
the clauses you have the same problem on Windows.

While you would have the same problem if you tried to do something
like "if e.errno == errno.EWIN:" on Linux, it's easier to circumvent
-- one of the many ways to do so is to write "if
errno.errorcode[e.errno] == 'EWIN':" instead..

> Compatibility could be preserved if the exceptions were made subclasses of
> OSError, so it would be trivial to catch any kind of OSError generically.
> PS: private email: accidental or intentional?

Accidental (my phone's experimental gmail client is missing a
reply-all). I'm adding python-ideas since that's where it belongs.

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

More information about the Python-ideas mailing list