[Python-Dev] str object going in Py3K (original) (raw)

Stefan Rank stefan.rank at ofai.at
Thu Feb 16 08:37:56 CET 2006

on 16.02.2006 06:59 Alex Martelli said the following:

On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:

On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:

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. If we go with two functions, I'd much rather hang them off of the file type object then add two new builtins. I really do think file.bytes() and file.text() (a.k.a. open.bytes() and open.text()) is better than opentext() or openbytes(). I agree, or, MAL's idea of bytes.open() and unicode.open() is also good. My fondest dream is that we do NOT have an 'open' builtin which has proven to be very error-prone when used in Windows by newbies (as evidenced by beginner errors as seen on c.l.py, the python-help lists, and other venues) -- defaulting 'open' to text is errorprone, defaulting it to binary doesn't seem the greatest idea either, principle "when in doubt, resist the temptation to guess" strongly suggests not having 'open' as a built-in at all. (And namemangling into openthis and openthat seems less Pythonic to me than exploiting namespaces by making structured names, either this.open and that.open or open.this and open.that). IOW, I entirely agree with Barry and Marc Andre.

opening a file, i.e. constructing a file object, always requires a path argument.

In case that Py3k manages to incorporate a Path object, I could be more natural to have .openbytes and .opentext as methods on Path objects. But bytes.open and text/unicode/str.open looks nice too.

Just for the record, stefan

More information about the Python-Dev mailing list