Guido van Rossum wrote: > On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> If we went with longer names, a slight variation on the opentext/openbinary >> idea would be to use opentext and opendata. > > After some thinking I don't like opendata any more -- often data is > text, so the term is wrong. openbinary is fine but long. So how about > openbytes? This clearly links the resulting object with the bytes > type, which is mutually reassuring. > > Regarding open vs. opentext, I'm still not sure. I don't want to > generalize from the openbytes precedent to openstr or openunicode > (especially since the former is wrong in 2.x and the latter is wrong > in 3.0). I'm tempting to hold out for open() since it's most > compatible.
Maybe a weird idea, but why not use static methods on the bytes and str type objects for this ?! E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0 renamed to str.openfile()) After all, you are in a certain way constructing object of the given types - only that the input to these constructors happen to be files in the file system. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 15 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________ 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
