On Mon, Feb 13, 2006 at 03:44:27PM -0800, Guido van Rossum wrote:
> But adding an encoding doesn't help. The str.encode() method always
> assumes that the string itself is ASCII-encoded, and that's not good
> enough:
> >>> "abc".encode("latin-1")
> 'abc'
> >>> "abc".decode("latin-1")
> u'abc'
> >
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> It's the consequences: nobody complains about tacking "const" on to a
>>> former honest-to-God "char *" argument that was in fact not modified,
>>> because that's not only helpful for C++ programmers, it's _harmless_
>>> for all programmers. For e
On 2/13/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Monday 13 February 2006 10:03, Georg Brandl wrote:
> > The above docs are from August 2005 while docs.python.org/dev is current.
> > Shouldn't the old docs be removed?
>
> I'm afraid I've generally been too busy to chime in much on th
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
Smith wrote:
> computing the bin boundaries for a histogram
> where bins are a width of 0.1:
>
for i in range(20):
> ... if (i*.1==i/10.)<>(nice(i*.1)==nice(i/10.)):
> ... print i,repr(i*.1),repr(i/10.),i*.1,i/10.
I don't see how that has any relevance to the way bin boundaries
would be
Guido van Rossum wrote:
> I also wonder if having a b"..." literal would just add more confusion
> -- bytes are not characters, but b"..." makes it appear as if they
> are.
I'm inclined to agree. Bytes objects are more likely to be used
for things which are *not* characters -- if they're characte
Guido van Rossum wrote:
> There's also the consideration for APIs that, informally, accept
> either a string or a sequence of objects.
My preference these days is not to design APIs that
way. It's never necessary and it avoids a lot of
problems.
Greg
_
Barry Warsaw wrote:
> This makes me think I want an unsigned byte type, which b[0] would
> return.
Come to think of it, this is something I don't
remember seeing discussed. I've been thinking
that bytes[i] would return an integer, but is
the intention that it would return another bytes
object?
Guido van Rossum wrote:
> In general I've come to appreciate that there are two ways of
> converting an object of type A to an object of type B: ask an A
> instance to convert itself to a B, or ask the type B to create a new
> instance from an A.
And the difference between the two isn't even alway
Guido van Rossum wrote:
> On 2/10/06, Mark Russell <[EMAIL PROTECTED]> wrote:
>> On 10 Feb 2006, at 12:45, Nick Coghlan wrote:
>>
>> An alternative would be to call it "__discrete__", as that is the key
>>
>> characteristic of an indexing type - it consists of a sequence of discrete
>>
>> values th
On 2/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > What would that imply for repr()? To support eval(repr(x))
>
> I don't think eval(repr(x)) needs to be supported for the bytes
> type. However, if that is desirable, it should return something
> like
>
> bytes([1,2,
Thanks to all for a rather insightful discussion, it's always fun to
learn that after 28 years of C programming the language still has
little corners that I know absolutely nothing about:-)
Practically speaking, though, I've adopted MAL's solution for the
time being:
> /* The keyword array
On 2/14/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > M.-A. Lemburg wrote:
> >>> It's the consequences: nobody complains about tacking "const" on to a
> >>> former honest-to-God "char *" argument that was in fact not modified,
> >>> because that's not only helpful for C
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> There's also the consideration for APIs that, informally, accept
>> either a string or a sequence of objects.
>
> My preference these days is not to design APIs that
> way. It's never necessary and it avoids a lot of
> problems.
On 2/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > The compiler in question is gcc and the warning can be turned off with
> > -Wno-write-strings. I think we'd be better off leaving that option
> > on, though. This warning will help me find places where I'm passing
On Feb 14, 2006, at 6:35 AM, Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> This makes me think I want an unsigned byte type, which b[0] would
>> return.
>
> Come to think of it, this is something I don't
> remember seeing discussed. I've been thinking
> that bytes[i] would return an integer, but is
On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:
> Phillip J. Eby wrote:
>> I was just pointing out that since byte strings are bytes by
>> definition,
>> then simply putting those bytes in a bytes() object doesn't alter the
>> existing encoding. So, using latin-1 when converting a string t
At 11:08 AM 2/14/2006 -0500, James Y Knight wrote:
>On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:
>
>>Phillip J. Eby wrote:
>>>I was just pointing out that since byte strings are bytes by
>>>definition,
>>>then simply putting those bytes in a bytes() object doesn't alter the
>>>existing enco
James Y Knight wrote:
> Kill the encoding argument, and you're left with:
>
> Python2.X:
> - bytes(bytes_object) -> copy constructor
> - bytes(str_object) -> copy the bytes from the str to the bytes object
> - bytes(sequence_of_ints) -> make bytes with the values of the ints,
> error on overflow
>> However I do dislike the name nice() - there is already a nice() in the
>> os module with a fairly well understood function. But I'm sure some
> Presumably it would be located somewhere like the math module.
For sure, but let's avoid as many name clashes as we can.
Python is very good at manag
James Y Knight <[EMAIL PROTECTED]> wrote:
> I like it, it makes sense. Unicode strings are simply not allowed as
> arguments to the byte constructor. Thinking about it, why would it be
> otherwise? And if you're mixing str-strings and unicode-strings, that
> means the str-strings you're some
On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote:
> >> However I do dislike the name nice() - there is already a nice() in the
> >> os module with a fairly well understood function. But I'm sure some
>
> > Presumably it would be located somewhere like the math module.
>
> For sure, but let's avoid
Guido van Rossum wrote:
> On 2/13/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> It'd be cruel and unusual punishment though to have to write
>>>
>>> bytes("abc", "Latin-1")
>>>
>>> I propose that the default encoding (for basestring instances) ought
>>> to be "ascii"
It doesn't seem to me that math.nice has an obvious meaning.
Regards,
Michael
On 2/14/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote:
> > >> However I do dislike the name nice() - there is already a nice() in the
> > >> os module with a fairly
On Feb 14, 2006, at 11:47 AM, M.-A. Lemburg wrote:
> The above approach would basically remove the possibility to easily
> create bytes() from literals in Py3k, since literals in Py3k create
> Unicode objects, e.g. bytes("123") would not work in Py3k.
That is true. And I think that is correct. The
On Feb 14, 2006, at 11:25 AM, Phillip J. Eby wrote:
> At 11:08 AM 2/14/2006 -0500, James Y Knight wrote:
>> I like it, it makes sense. Unicode strings are simply not allowed as
>> arguments to the byte constructor. Thinking about it, why would it be
>> otherwise? And if you're mixing str-strings a
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'
On 2/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I'm actually opposed to bdist_egg, from a conceptual point of view.
> I think it is wrong if Python creates its own packaging format
> (just as it was wrong that Java created jar files - but they are
> without deployment procedures even tod
On Mon, Feb 13, 2006 at 08:07:49PM -0800, Guido van Rossum wrote:
> On 2/13/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> > "\x80".encode('latin-1')
>
> But in 2.5 we can't change that to return a bytes object without
> creating HUGE incompatibilities.
People could spell it bytes(s.encode
(Disclaimer: I'm not currently promoting the addition of bdist_egg or any
egg-specific features for the 2.5 timeframe, but neither am I
opposed. This message is just to clarify a few points and questions under
discussion, not to advocate a particular outcome. If you read this and
think you se
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, Michael Walter <[EMAIL PROTECTED]> wrote:
> It doesn't seem to me that math.nice has an obvious meaning.
I don't disagree, I think math.nice is a terrible name. I was
objecting to the desire to try to come up with interesting, different
names in every module namespace.
> Regards,
> Mi
On Tue, Feb 14, 2006 at 11:16:32AM -0800, Guido van Rossum wrote:
> Well, just like Java, if you have pure Python code, why should a
> developer have to duplicate the busy-work of creating distributions
> for different platforms? (Especially since there are so many different
> target platforms --
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In private email, Phillip Eby suggested to add these things to the
> 2.5. standard library:
>
> bdist_deb, bdist_msi, and friends
>
> He explained them as follows:
>
> """
> bdist_deb makes .deb files (packages for D
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
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() fo
I'm about to send 6 or 8 replies to various salient messages in the
PEP 332 revival thread. That's probably a sign that there's still a
lot to be sorted out. In the mean time, to save you reading through
all those responses, here's a summary of where I believe I stand.
Let's continue the discussion
On 2/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >>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
On 2/14/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 13, 2006 at 03:44:27PM -0800, Guido van Rossum wrote:
>
> > But adding an encoding doesn't help. The str.encode() method always
> > assumes that the string itself is ASCII-encoded, and that's not good
> > enough:
>
> > >>> "abc".en
On 2/14/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I'm starting to wonder, do we really need anything fancy? Wouldn't it
> be sufficient to have a way to compactly store 8-bit integers?
>
> In 2.x we could convert unicode like this:
> bytes(ord(c) for c in u"It's...".encode('utf-8'))
Yuck.
> u"
On 2/13/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> This makes me think I want an unsigned byte type, which b[0] would
> return. In another thread I think someone mentioned something about
> fixed width integral types, such that you could have an object that
> was guaranteed to be 8-bits wide, 1
On 2/13/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> What would that imply for repr()? To support eval(repr(x)) it would
> have to produce whatever format the source code includes to begin
> with.
I'm not sure that's a requirement. (I do think that in 2.x,
str(bytes(s)) == s should hold as long as
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
> >On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > I didn't mean that it was the only purpose. In Python 2.x, practical code
> > > has to sometimes deal with "string-like" objec
On 2/14/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> A related question: what would bytes([104, 101, 108, 108, 111, 8004])
> return? An exception hopefully.
Absolutely.
> I also think you'd want bytes([x
> for x in some_bytes_object]) to return an object equal to the original.
You mean if type
On 2/14/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > As Phillip guessed, I was indeed thinking about introducing bytes()
> > sooner than that, perhaps even in 2.5 (though I don't want anything
> > rushed).
>
> Hmm, that is probably going to be too early. As the thread
On Feb 14, 2006, at 2:05 PM, Joe Smith wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> In private email, Phillip Eby suggested to add these things to the
>> 2.5. standard library:
>>
>> bdist_deb, bdist_msi, and friends
>>
>> He explained them as fol
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 Tue, Feb 14, 2006 at 05:05:08PM -0500, Joe Smith wrote:
> I don't like the idea of bdist_deb very much.
> The idea behind the debian packaging system is that unlike with RPM and
> Windows, package management should be clean.
The idea behind RPM is also that package management should be clean.
On Feb 14, 2006, at 3:13 PM, Guido van Rossum wrote:
> I'm about to send 6 or 8 replies to various salient messages in the
> PEP 332 revival thread. That's probably a sign that there's still a
> lot to be sorted out. In the mean time, to save you reading through
> all those responses, here's a su
On Tue, Feb 14, 2006 at 03:13:37PM -0800, Guido van Rossum wrote:
> Also, bytes objects are (in my mind anyway) mutable. We have no other
> literal notation for mutable objects. What would the following code
> print?
>
> for i in range(2):
> b = b"abc"
> print b
> b[0] = ord("A")
>
At 03:14 PM 2/14/2006 -0800, Bob Ippolito wrote:
>I'm also not sure what the uninstallation story
>with scripts is.
The scripts have enough breadcrumbs in them that you can figure out what
egg they go with. More precisely, an egg contains enough information for
you to search PATH for its script
On 2/14/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> People could spell it bytes(s.encode('latin-1')) in order to make it
> work in 2.X. That spelling would provide a way of ensuring the type
> of the return value.
At the cost of an extra copying step.
[Guido]
> > You missed the part where
On Tue, 2006-02-14 at 15:13 -0800, Guido van Rossum wrote:
> So I'm taking that the specific properties you want to model are the
> overflow behavior, right? N-bit unsigned is defined as arithmethic mod
> 2**N; N-bit signed is a bit more tricky to define but similar. These
> never overflow but ins
On 2/14/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Maybe you should ask your coworkers. :-) I think gmail is trying to
> do something intelligent with the Mail-Followup-To header.
But you're the only person for whom it does that. Do you have a funny
gmail setting?
--
--Guido van Rossum (h
On 2/14/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On Feb 14, 2006, at 3:13 PM, Guido van Rossum wrote:
> > - we need a new PEP; PEP 332 won't cut it
> >
> > - no b"..." literal
> >
> > - bytes objects are mutable
> >
> > - bytes objects are composed of ints in range(256)
> >
> > - you can pass
On Tue, Feb 14, 2006 at 03:13:25PM -0800, Guido van Rossum wrote:
> Martin von Loewis's alternative for the "very controversial" set is to
> disallow an encoding argument and (I believe) also to disallow Unicode
> arguments. In 3.0 this would leave us with s.encode() as the
> only way to convert a
Jeremy Hylton wrote:
>>Perhaps there is some value in finding functions which ought to expect
>>const char*. For that, occasional checks should be sufficient; I cannot
>>see a point in having code permanently pass with that option. In
>>particular not if you are interfacing with C libraries.
>
>
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I don't think you're doing anyone any favours by trying to protect
> them from having to know about these things, because they *need* to
> know about them if they're not to write algorithms that seem to
> work fine on test
On 2/14/06, Neil Schemenauer wrote:
> People could spell it bytes(s.encode('latin-1')) in order to make it
> work in 2.X.
Guido wrote:
> At the cost of an extra copying step.
That sounds like an implementation issue. If it is important
enough to matter, then why not just add some smarts to the
[Guido van Rossum]
> Somewhat controversial:
>
> - bytes("abc") == bytes(map(ord, "abc"))
At first glance, this seems obvious and necessary, so if it's somewhat
controversial, then I'm missing something. What's the issue?
Raymond
___
Python-Dev mail
Bob Ippolito wrote:
>>Martin von Loewis's alternative for the "very controversial" set is to
>>disallow an encoding argument and (I believe) also to disallow Unicode
>>arguments. In 3.0 this would leave us with s.encode() as the
>>only way to convert a string (which is always unicode) to bytes. The
Thomas Wouters wrote:
> Actually, that's where distutils and bdist_* comes in. Mr. Random Developer
> writes a regular distutils setup.py, and I can install the latest,
> not-quite-in-apt version by doing 'setup.py bdist_deb' and installing the
> resulting .deb.
Why not just do 'setup.py install'
On Feb 14, 2006, at 4:17 PM, Guido van Rossum wrote:
> On 2/14/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> On Feb 14, 2006, at 3:13 PM, Guido van Rossum wrote:
>>> - we need a new PEP; PEP 332 won't cut it
>>>
>>> - no b"..." literal
>>>
>>> - bytes objects are mutable
>>>
>>> - bytes objects
On Wed, Feb 15, 2006 at 01:51:03PM +1300, Greg Ewing wrote:
> Thomas Wouters wrote:
> > Actually, that's where distutils and bdist_* comes in. Mr. Random Developer
> > writes a regular distutils setup.py, and I can install the latest,
> > not-quite-in-apt version by doing 'setup.py bdist_deb' and
Joe Smith wrote:
> Windows and RPM are known for major dependency problems, letting packages
> damage each other, having packages that do not uninstall cleanly (i.e.
> packages that leave junk all over the place) and generally messing the sytem
> up quite baddly over time, so that the OS is usu
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
Raymond Hettinger wrote:
>>- bytes("abc") == bytes(map(ord, "abc"))
>
>
> At first glance, this seems obvious and necessary, so if it's somewhat
> controversial, then I'm missing something. What's the issue?
There is an "implicit Latin-1" assumption in that code. Suppose
you do
# -*- coding:
On 2/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 2/14/06, Neil Schemenauer wrote:
> > People could spell it bytes(s.encode('latin-1')) in order to make it
> > work in 2.X.
>
> Guido wrote:
> > At the cost of an extra copying step.
>
> That sounds like an implementation issue. If it is impor
[Greg Ewing wrote]
> MacOSX seems to be the only system so far that has got
> this right -- organising the system so that everything
> related to a given application or library can be kept
> under a single directory, clearly labelled with a
> version number.
ActivePython and MacPython have to inst
Guido van Rossum wrote:
> The only remaining question is what if anything to do with an
> encoding argment when the first argument is of type str...)
From what you said earlier about str in 2.x being
interpretable as a unicode string which contains
only ascii, it seems to me that if you say
On Feb 14, 2006, at 5:00 PM, Greg Ewing wrote:
> Joe Smith wrote:
>
>> Windows and RPM are known for major dependency problems, letting
>> packages
>> damage each other, having packages that do not uninstall cleanly
>> (i.e.
>> packages that leave junk all over the place) and generally messin
On Wed, Feb 15, 2006 at 02:00:21PM +1300, Greg Ewing wrote:
> Joe Smith wrote:
>
> > Windows and RPM are known for major dependency problems, letting packages
> > damage each other, having packages that do not uninstall cleanly (i.e.
> > packages that leave junk all over the place) and generally
Guido van Rossum wrote:
> On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
>>
>>>On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>>
>>>What would bytes("abc\xf0", "latin-1") *mean*?
>>
>>I'm saying that XXX would be the same enc
On Feb 14, 2006, at 5:22 PM, Trent Mick wrote:
> [Greg Ewing wrote]
>> MacOSX seems to be the only system so far that has got
>> this right -- organising the system so that everything
>> related to a given application or library can be kept
>> under a single directory, clearly labelled with a
>>
Trent Mick wrote:
> ActivePython and MacPython have to install stuff to:
>
> /usr/local/bin/...
> /Library/Frameworks/Python.framework/...
> /Applications/MacPython-2.4/... # just MacPython does this
It's not perfect, but it's still a lot better than the
situation on any other unix
Thomas Wouters wrote:
> Well, as an end user, I honestly don't care.
> As a programmer, I also don't care.
Perhaps I've been burned once too often by someone's
oh-so-clever installer script screwing up and leaving
me to wade through an impenetrable pile of makefiles,
shell scripts and m4 macros t
Thomas Wouters wrote:
>
> The encoding of network streams or files may be
> entirely unknown beforehand, and depend on the content: a content-encoding,
> a HTML tag. Will bytes-strings get string methods for easy
> searching of content descriptors?
Seems to me this is a case where you want to be
Guido van Rossum wrote:
> I'm about to send 6 or 8 replies to various salient messages in the
> PEP 332 revival thread. That's probably a sign that there's still a
> lot to be sorted out. In the mean time, to save you reading through
> all those responses, here's a summary of where I believe I stan
Greg Ewing wrote:
> Guido van Rossum wrote:
>> On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>
>>> At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
>>>
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
What would bytes("abc\xf0", "latin-1") *mean*?
>>> I'm saying th
After some revisions, PEP 357 is ready for more comments. Please voice
any concerns.
-Travis
PEP: 357
Title: Allowing Any Object to be Used for Slicing
Version: $Revision: 42367 $
Last Modified: $Date: 2006-02-14 18:12:07 -0700 (Tue, 14 Feb 2006) $
Author: Travis Oliphant <[EMAIL PROTECTED]>
St
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
On Tuesday 14 February 2006 22:34, Greg Ewing wrote:
> Seems to me this is a case where you want to be able
> to change encodings in the middle of reading the stream.
> You start off reading the data as ascii, and once you've
> figured out the encoding, you switch to that and carry
> on readin
On Tuesday 14 February 2006 03:09, Neal Norwitz wrote:
> While you are here, are you planning to do the doc releases for 2.5?
> You are tentatively listed in PEP 356. (Technically it says TBD with
> a ? next to your name.)
Releases generally aren't a problem, since they're heavily automated an
On 2/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
> >>- bytes("abc") == bytes(map(ord, "abc"))
> >
> >
> > At first glance, this seems obvious and necessary, so if it's somewhat
> > controversial, then I'm missing something. What's the issue?
>
> There is an "impl
On 2/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/14/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > In 3.0 it changes to:
> > "It's...".encode('utf-8')
> > u"It's...".byteencode('utf-8') # Same as above, kept for compatibility
>
> No. 3.0 won't have "backward compatibility" features. T
On 2/14/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>
> Releases generally aren't a problem, since they're heavily automated and
> scheduled well in advance. I'm glad to continue helping with that,
> especially since that seems to be about all I can get to sometimes.
Great, I updated the PE
On 2/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/13/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > If I understand correctly there's three main candidates:
> > 1. Direct copying to str in 2.x, pretending it's latin-1 in unicode in 3.x
>
> I'm not sure what you mean, but I'm guessing yo
On 2/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Not entirely, since I don't know what b"abcdef" would mean
> (where is a Unicode Euro character typed in whatever source
> encoding was used).
SyntaxError I would hope. Ascii and hex escapes only please. :)
Although I'm not arguing for o
I was hoping to get a lot more feedback about PEP 356 and the 2.5
release schedule.
http://www.python.org/peps/pep-0356.html
I updated the schedule it is now:
alpha 1: May 6, 2006 [planned]
alpha 2: June 3, 2006 [planned]
alpha 3: July 1, 2006 [planned]
beta 1: July 29, 2006 [pl
We (the pythonmac-sig mailing list) seem to have converged (almost --
still talking about the logo) on a new download page for MacPython, to
replace the page currently at
http://www.python.org/download/download_mac.html. The strawman can be
seen at http://bill.janssen.org/mac/new-macpython-page.ht
On 2/14/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I was hoping to get a lot more feedback about PEP 356 and the 2.5
> release schedule.
>
> http://www.python.org/peps/pep-0356.html
>
> I updated the schedule it is now:
>
> alpha 1: May 6, 2006 [planned]
> alpha 2: June 3, 2006 [planned]
Attached is the 2.5 release PEP 356. It's also available from:
http://www.python.org/peps/pep-0356.html
Does anyone have any comments? Is this good or bad? Feel free to
send to me comments.
We need to ensure that PEPs 308, 328, and 343 are implemented. We
have possible volunteers for 308 and
Ron Adam wrote:
> My first impression and thoughts were: (and seems incorrect now)
>
> bytes(object) -> byte sequence of objects value
>
> Basically a "memory dump" of objects value.
As I understand the current intentions, this is correct.
The bytes constructor would have two different s
Fred L. Drake, Jr. wrote:
> The proper response in this case is often to re-start decoding
> with the correct encoding, since some of the data extracted so far may have
> been decoded incorrectly.
If the protocol has been sensibly designed, that shouldn't
happen, since everything up to the codi
On Wednesday 15 February 2006 01:44, Greg Ewing wrote:
> If the protocol has been sensibly designed, that shouldn't
> happen, since everything up to the coding marker should
> be ascii (or some other protocol-defined initial coding).
Indeed.
> For protocols that are not sensibly designed (or
96 matches
Mail list logo
