[Python-Dev] str object going in Py3K
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
>> 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.
`open`ing a file, i.e. constructing a `file` object, always requires a
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,
More information about the Python-Dev