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

[Moving to python-ideas]

On Thu, Apr 2, 2009 at 9:12 AM, Gustavo Carneiro <gjcarneiro@gmail.com> wrote:

...

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

...

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

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

[Moving to python-ideas]

On Thu, Apr 2, 2009 at 9:12 AM, Gustavo Carneiro <gjcarneiro@gmail.com> wrote:

...

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

...

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