A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061152.html below:

[Python-Dev] str object going in Py3K

[Python-Dev] str object going in Py3KShane Holloway (IEEE) shane.holloway at ieee.org
Thu Feb 16 18:20:24 CET 2006
On Feb 15, 2006, at 20:06, Greg Ewing wrote:

> Barry Warsaw wrote:
>
>> 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'm worried about feeping creaturism of the file type
> here. To my mind, the file type already has too many
> features, and this hinders code that wants to define
> its own file-like objects.
>
> In 3.0 I'd like to see the file type reduced to having
> as simple an interface as possible (basically just
> read/write) and all other stuff (readlines, text codecs,
> etc.) implemented as wrappers around it.

I'd like to put my 2 cents in a agree with Greg here.  Implementing a  
"complete" file-like object has come to be something of a pain.   
Perhaps we can do something akin to UserDict -- perhaps UserTextFile  
and UserBinaryFile?  It would be nice if it could handle the default  
implementation of everything but read and write.

Thanks,
-Shane

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4