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

[Moving to python-ideas] On Thu, Apr 2, 2009 at 9:12 AM, Gustavo Carneiro wrote:

2009/4/2 Guido van Rossum

...

On 4/2/09, Gustavo Carneiro 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: 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..

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/)