Martin v. Löwis wrote:
>>Another thought -- what is going to happen to os.open?
>>Will it change to return bytes, or will there be a new
>>os.openbytes?
>
> Nit-pickingly: os.open will continue to return integers.
Sorry, what I meant was will os.read return bytes.
Greg
_
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> What will be the explicit way to open a file in bytes mode
>>> and in text mode (I for one would like to move away from
>>> open() completely as well) ?
>>>
>>> Will we have a single file
Guido van Rossum wrote:
> On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> What will be the explicit way to open a file in bytes mode
>> and in text mode (I for one would like to move away from
>> open() completely as well) ?
>>
>> Will we have a single file type with two different modes
>>
Guido van Rossum wrote:
> On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> What will be the explicit way to open a file in bytes mode
>> and in text mode (I for one would like to move away from
>> open() completely as well) ?
>>
>> Will we have a single file type with two different modes
>>
On 2/15/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >My expectation is that the Py3k standard I/O library will do all of
> >its own conversions on top of binary files anyway -- if you missed it,
> >I'd like to g
Bengt Richter wrote:
> On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
>> [...]
>> My expectation is that the Py3k standard I/O library will do all of
>> its own conversions on top of binary files anyway -- if you missed it,
>> I'd like to get rid of any ties
On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> What will be the explicit way to open a file in bytes mode
> and in text mode (I for one would like to move away from
> open() completely as well) ?
>
> Will we have a single file type with two different modes
> or two different types ?
I'm cu
Greg Ewing wrote:
> Another thought -- what is going to happen to os.open?
> Will it change to return bytes, or will there be a new
> os.openbytes?
Nit-pickingly: os.open will continue to return integers.
I think it should return OS handles on Windows, instead
of C library handles. (also notice t
On 2/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> I agree, or, MAL's idea of bytes.open() and unicode.open() is also
> good.
No, the bytes and text data types shouldn't have to be tied to the I/O
system. (The latter tends to evolve at a much faster rate so should be
isolated.)
> My fondest d
Guido van Rossum wrote:
> On 2/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> I agree, or, MAL's idea of bytes.open() and unicode.open() is also
>> good.
>
> No, the bytes and text data types shouldn't have to be tied to the I/O
> system. (The latter tends to evolve at a much faster rate so sh
On Wed, 15 Feb 2006 21:59:55 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>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
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 tha
On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 2/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > So how about
>> > openbytes? This clearly links the resulting object with the bytes
>> > type, which is mutually reassuring.
>>
>> That
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
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
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 creat
M.-A. Lemburg wrote:
> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
> renamed to str.openfile())
This seems wrong to me, because it creates an unnecessary
dependency of the bytes/str/unicode types on the file type.
These types should remain strictly focused on being just
containers
On 2/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So how about
> > openbytes? This clearly links the resulting object with the bytes
> > type, which is mutually reassuring.
>
> That looks quite nice.
>
> Another thought -- what is going to happen to os.open?
> Will it
Guido van Rossum wrote:
> So how about
> openbytes? This clearly links the resulting object with the bytes
> type, which is mutually reassuring.
That looks quite nice.
Another thought -- what is going to happen to os.open?
Will it change to return bytes, or will there be a new
os.openbytes?
--
On 2/15/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> I'm intrigued by the encoding guessing techniques you envisage.
Don't hold your breath. *I* am not very interested in guessing
encodings -- I was just commenting on posts by others that mentioned
difficulties caused by this approach. My posit
Guido van Rossum wrote:
> On 2/15/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
>> Forcing the programmer to be aware of encodings, also pushes the same
>> requirement onto the user (who is often the source of the text in question).
>>
>
> The programmer shouldn't have to be aware of encodings
On 2/15/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Well, I probably am, but that's not the reason. Reading has nothing
> to do with it.
Actually if you read binary data in text mode on Windows you also get
corrupt (and often truncated) data, unless you're lucky enough that
the binary data cont
Well, I probably am, but that's not the reason. Reading has nothing
to do with it.
The default mode (text) corrupts data on write on a certain platform
(Windows) by inserting extra bytes in the data stream. This bug
particularly exhibits itself when programs developed on Linux or Mac
OS X are th
On 2/15/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> The default behavior of the current open() in opening files as text is
> particularly grating.
Why? Are you perhaps one of those rare folks who read more binary data
than text?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
> 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().
+1.
The default behavior of the current open() in o
On 2/15/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Barry Warsaw wrote:
> > On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> >
> >> 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.openfi
On Wed, 2006-02-15 at 19:02 +0100, M.-A. Lemburg wrote:
> Anyway, as long as we don't start adding openthis() and openthat()
> I guess I'm happy ;-)
Me too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
Barry Warsaw wrote:
> On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
>
>> 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())
>
> That's also not
On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> 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())
That's also not a bad idea, but I'd leave off o
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 o
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
On 2/15/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
> Forcing the programmer to be aware of encodings, also pushes the same
> requirement onto the user (who is often the source of the text in question).
The programmer shouldn't have to be aware of encodings most of the
time -- it's the job of the I/O
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 lon
On Feb 15, 2006, at 7:19 AM, Fuzzyman wrote:
> [snip..]
>
> I personally like the move towards all unicode strings, basically
> any text where you don't know the encoding used is 'random binary
> data'. This works fine, so long as you are in control of the text
> source. *However*, it leaves
Adam Olsen wrote:
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
+1 for two functions.
My choice would be open() for binary and opentext() for text. I don't
find that backwards at all: the text function is going to be more
different from the current open() function then th
Guido van Rossum wrote:
> But somehow I still like the 'open' verb. It has a long and rich
> tradition. And it also nicely conveys that it is a factory function
> which may return objects of different types (though similar in API)
> based upon either additional arguments (e.g. buffering) or the
> e
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
> +1 for two functions.
>
> My choice would be open() for binary and opentext() for text. I don't
> find that backwards at all: the text function is going to be more
> different from the current open() function then the binary function
> would
Alex Martelli wrote:
> What about shorter names, such as 'text' instead of 'opentext' and
> 'data' instead of 'openbinary'?
Because those words are just names for pieces of data,
with nothing to connect them with files or the act of
opening a file.
I think the association of "open" with "file" i
On Tue, Feb 14, 2006 at 05:48:57PM -0500, Barry Warsaw wrote:
> On Tue, 2006-02-14 at 14:37 -0800, Alex Martelli wrote:
>
> > What about shorter names, such as 'text' instead of 'opentext' and
> > 'data' instead of 'openbinary'? By eschewing the 'open' prefix we
> > might make it easy to eventual
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > [...] surely text files are more commonly used, and surely the
> > most common operation should have the shorter name -- call it the
> > Huffman Principle.
>
> +1 for two functions.
>
> My choice would be open() fo
On Tue, 2006-02-14 at 14:37 -0800, Alex Martelli wrote:
> What about shorter names, such as 'text' instead of 'opentext' and
> 'data' instead of 'openbinary'? By eschewing the 'open' prefix we
> might make it easy to eventually migrate off it. Maybe text and data
> could be two subclasses of file
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
...
> Maybe it's even better to use opentext() AND openbinary(), and deprecate
> plain open(). We could even introduce them at the same time as bytes()
> (and leave the open() deprecation for 3.0).
What about shorter names, such as 'text' i
Guido van Rossum wrote:
> > what will
> > ``open(filename).read()`` return ?
>
> Since you didn't specify an open mode, it'll open it as a text file
> using some default encoding (or perhaps it can guess the encoding from
> file metadata -- this is all OS specific). So it'll return a string.
>
>
On 2/14/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
> In Python 3K, when the string data-type has gone,
Technically it won't be gone; str will mean what it already means in
Jython and IronPython (for which CPython uses unicode in 2.x).
> what will
> ``open(filename).read()`` return ?
Since you didn'
Guido van Rossum wrote:
> [snip..]
>
>>In py3k, when the str object is eliminated, then what do you have?
>>Perhaps
>>- bytes("\x80"), you get an error, encoding is required. There is no
>>such thing as "default encoding" anymore, as there's no str object.
>>- bytes("\x80", encoding="latin-1"), yo
45 matches
Mail list logo
