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

2009-04-02 Thread Gustavo Carneiro
Apologies if this has already been discussed.

I was expecting that by now, python 3.0, 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 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?

Regards,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
The universe is always one step beyond logic. -- Frank Herbert
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2009-04-02 Thread Benjamin Peterson
2009/4/2 Gustavo Carneiro gjcarne...@gmail.com:
 Apologies if this has already been discussed.

I don't believe it has ever been discussed to be implemented.

 Apparently no one has bothered yet 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?

Python doesn't need any more builtin exceptions to clutter the
namespace. Besides, what's wrong with just checking the errno?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2009-04-02 Thread Jack diederich
On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson benja...@python.org wrote:
 2009/4/2 Gustavo Carneiro gjcarne...@gmail.com:
 Apologies if this has already been discussed.

 I don't believe it has ever been discussed to be implemented.

 Apparently no one has bothered yet 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?

 Python doesn't need any more builtin exceptions to clutter the
 namespace. Besides, what's wrong with just checking the errno?

The problem is manpower (this has been no ones itch).  In order to
have a hierarchy of OSError exceptions the underlying code would have
to raise them.  That means diving into all the C code that raises
OSError and cleaning them up.

I'm +1 on the idea but -1 on doing the work myself.

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2009-04-02 Thread Gustavo Carneiro
(cross-posting back to python-dev to finalize discussions)

2009/4/2 Guido van Rossum gu...@python.org
[...]

  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.

 Yeah, but now you'd have to generate the list of exceptions (which
 would be enormously long) based on the union of all errno codes in the
 universe.

 Unless you only want to do it for some errno codes and not for others,
 which sounds like asking for trouble.

 Also you need a naming scheme that works for all errnos and doesn't
 require manual work. Frankly, the only scheme that I can think of that
 could be automated would be something like OSError_ENAME.

 And, while OSError is built-in, I think these exceptions (because
 there are so many) should not be built-in, and probably not even live
 in the 'os' namespace -- the best place for them would be the errno
 module, so errno.OSError_ENAME.

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

 It's an enormous amount of work to make it happen across all
 platforms. And it doesn't really solve an important problem.


I partially agree.  It will be a lot of work.  I think the problem is valid,
although not very important, I agree.




  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!).

 That doesn't strike me as correct at all, since it doesn't distinguish
 between ENOENT being raised for some file deep down in the tree vs.
 the root not existing. (This could happen if after you did
 os.listdir() some other process deleted some file.)


OK.  Maybe in a generic case this could happen, although I'm sure this won't
happen in my particular scenario.  This is about a build system, and I am
assuming there are no two concurrent builds (or else a lot of other things
would fail anyway).


 A better way might be

 try:
  shutil.rmtree(dir)
 except OSError:
  if os.path.exists(dir):
   raise


Sure, this works, but at the cost of an extra system call.  I think it's
more elegant to check the errno (assuming the corner case you pointed out
above is not an issue).


 Though I don't know what you wish to happen of dir were a dangling
 symlink.

  What I am proposing is that the simpler correct code would be something
  like:
 
  try:
  shutil.rmtree(dirname)
  except OSNoEntryError:
  pass
 
  Much simpler, no?

 And wrong.

  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.

 Thanks for not wasting any more of my time.


OK, I won't waste more time.  If this were an obvious improvement beyond
doubt to most people, I would pursue it, but since it's not, I can live with
it.

Thanks anyway,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
The universe is always one step beyond logic. -- Frank Herbert
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com