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 to C's
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 get rid of
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
or two
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
or two
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
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 precedent to
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 should be
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 dream
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
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 currently
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 the
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 long.
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
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 wrong.
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
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 one
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 a bad idea,
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
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
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/)
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
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
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 most of
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
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, 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 change to
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
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
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
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 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 looks quite nice.
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), you get a bytestring
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't
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.
If you
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'
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:
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() for binary and
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 eventually
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 is
39 matches
Mail list logo
