[Python-Dev] str object going in Py3K

[Stefan Rank]

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.
> 

`open`ing 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