Guido van Rossum wrote:
> But somehow I still like the 'open' verb. It has a long and rich
> tradition. And it also nicely conveys that it is a factory function
> which may return objects of different types (though similar in API)
> based upon either additional arguments (e.g. buffering) or the
> environment (e.g. encodings) or even inspection of the file being
> opened.
If we went with longer names, a slight variation on the opentext/openbinary
idea would be to use opentext and opendata.
That is, "give me something that looks like a text file (it contains
characters)", or "give me something that looks like a data file (it contains
bytes)".
"opentext" would map to "codecs.open" (that is, accepting an encoding argument)
"opendata" would map to the standard "open", but with the 'b' in the mode
string added automatically.
So the mode choices common to both would be:
'r'/'w'/'a' - read/write/append (default 'r')
''/'+' - update (IOError if file does not already exist) (default '')
opentext would allow the additional option:
''/'U' - universal newlines (default '')
Neither of them would accept a 'b' in the mode string.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
