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

[Gustavo Carneiro]

2009/4/2 Guido van Rossum <guido at python.org>

> [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."


Sorry.  I suck at this.  I think I'm too impatient (read: time constrained)
to be polite :P


>
> >> > 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?"


Maybe I didn't express myself very well.  By "no will to do it" I meant "no
interest to do it".  If you thought it was a bad idea you would have no
interest in doing it.

To be frank, what I thought most likely was that, with all the refactoring
going on in Python 3, this issue, which was an obvious cleanup to me (but
now I realize it is not obvious at all to everyone else), was overlooked
because there were bigger problems to solve.

So there are usually only three reasons why something is not done:

  1- It's a bad idea;
  2- No one thought of it;
  3- It's a good and known idea, but there was no manpower to do it.

I was betting more on 2 and 3, but not entirely ruling out 1.


>
> >> 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:
>
>  try:
>    ...
>  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..
>

I just committed some code like "if e.errno == errno.EWIN".  I  had not
realized not all constants are defined on all systems, although it is
documented so I have no excuse.

The problem you report:

>  try:
>    ...
>  except OSWinError:
>    ...
>  except OSLinError:
>    ...
>
>
Would be solved if both OSWinError and OSLinError were always defined in
both Linux and Windows Python.  Programs could be written to catch both
OSWinError and OSLinError, except that on Linux OSWinError would never
actually be raised, and on Windows OSLinError would never occur.  Problem
solved.

The downsides of this?  I can only see memory, at the moment, but I might be
missing something.

Now just one final word why I think this matters.  The currently correct way
to remove a directory tree and only ignore the error "it does not exist" is:

try:
    shutil.rmtree("dirname")
except OSError, e:
    if errno.errorcode[e.errno] != 'ENOENT':
       raise

However, only very experienced programmers will know to write that correct
code (apparently I am not experienced enought!).

What I am proposing is that the simpler correct code would be something
like:

try:
    shutil.rmtree("dirname")
except OSNoEntryError:
    pass

Much simpler, no?

Right now, developers are tempted to write code like:

    shutil.rmtree("dirname", ignore_errors=True)

Or:

try:
    shutil.rmtree("dirname")
except OSError:
    pass

Both of which follow the error hiding anti-pattern [1].

[1] http://en.wikipedia.org/wiki/Error_hiding

Thanks for reading this far.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090402/3f7389a4/attachment.html>