On 13Mar2014 11:22, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Cameron Simpson <c...@zip.com.au> writes: > > Therefore you need to continue _only_ if you get EEXIST. Otherwise > > abort. > > If you target Python 3.3 or later, you can catch “FileExistsError” > <URL:http://docs.python.org/3/library/exceptions.html#FileExistsError> > which is far simpler than messing around with ‘errno’ values.
Yes and no. Firstly, we Old Farts find these new ways confusing:-) Secondly, and perhaps more importantly, if I were using the O_EXCL et al constants in a call to os.open as the OP is doing, I would want to be equally picky about what I recognise in the exception; I _want_ to use error explicitly. In particular, the behaviour of "os.open" is pretty much a bare metal call to the POSIX "open(2)" OS interface, and so I want my response to be framed directly in terms of the documented error responses for that API. Thus, errno values. Finally, if I were grouping my responses to the exception by type and perhaps performing a few different actions depending on the error, then the new class hierachy is a good way to do it. But for this instance, IMO, we're catching exactly one failure mode as "retry with another name" and reraising anything else. So I don't find an errno test any less readable that a class comparison, and it still feels more precise to me. Cheers, -- Cameron Simpson <c...@zip.com.au> The road less traveled is FASTER !! - Luc Marcouiller, marco...@ireq.hydro.qc.ca -- https://mail.python.org/mailman/listinfo/python-list