On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote: > On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman <p...@phdru.name> wrote: > > Why doesn't open() return None for a non-existing file? or > > socket.gethostbyname() for a non-existing name? > > That's not an answer to my question, because those calls have very > important use cases where the user knows the object exists (and in > fact in some cases open() will create it for him), so that failure to > exist is indeed a (user) error (such as a misspelling). I find it > hard to imagine use cases where "file = open(thisfile) or > open(thatfile)" makes sense. Not even for the case where thisfile == > 'script.pyc' and thatfile == 'script.py'.
Counterexamples - any configuration file: a program looks for its config at $HOME and not finding it there looks in /etc. So config = open('~/.someprogram.config') or open('/etc/someprogram/config') would make sense. The absence of any of these files is not an error at all - the program just starts with default configuration. So if the resulting config in the code above would be None - it's still would be ok. But Python doesn't allow that. Some configuration files are constructed by combining a number of user-defined and system-defined files. E.g., the mailcap database. It should be something like combined_database = [db for db in ( open('/etc/mailcap'), open('/usr/etc/mailcap'), open('/usr/local/etc/mailcap'), open('~/.mailcap'), ) if db] But no way - open() raises IOError, not return None. And I think it is the right way. Those who want to write the code similar to the examples above - explicitly suppress exceptions by writing wrappers. > The point of the proposed get_clock(), OTOH, is to ask if an object > with certain characteristics exists, and the fact that it returns the > clock rather than True if found is a matter of practical convenience. > Precisely because "clock = get_clock(best) or get_clock(better) or > get_clock(acceptable)" does make sense. Oleg. -- Oleg Broytman http://phdru.name/ p...@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ 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