Adam Olsen wrote:
My assumption is these would become errors in 3.x. bytes(str) is only
needed so you can do bytes(uabc.encode('utf-8')) and have it work in
2.x and 3.x.
I think the proposal for bytes(seq) to mean bytes(map(ord, seq))
was meant to be valid for both 2.x and 3.x, on the grounds
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).
XML, for one protocol, requires you to restart over. The
initial sequence could be UTF-16, or it could
Neal Norwitz wrote:
What do people think about that? There are still a lot of features we
want to add. Is this ok with everyone? Do you think it's realistic?
My view on schedules is that they need to exist, whether they are
followed or not. So having one is orders of magnitude better than
Hi,
2 questions:
- is (c)ElementTree still planned for inclusion ?
- isn't the current implementation of itertools.tee (cache of previous
generated values) incompatible with the new possibility to feed a
generator (PEP 342) ?
Regards
Neal Norwitz a écrit :
Attached is the 2.5
Bob Ippolito wrote:
** The exception is scripts. Scripts go wherever --install-scripts=
point to, and AFAIK there is no means to ensure that the scripts from
one egg do not interfere with the scripts for another egg or anything
else on the PATH. I'm also not sure what the
As per Neal's prodding email, here is a thread to discuss where we
want to go with the C AST to Python stuff and what I think are the
core issues at the moment.
First issue is the ast-objects branch. Work is being done on it, but
it still leaks some references (Neal or Martin can correct me if I
On 2/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Adam Olsen wrote:
(I wonder if maybe they should be an error in 2.x as well. Source
encoding is for unicode literals, not str literals.)
Source encoding applies to the entire source code, including (byte)
string literals, comments,
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M James Y Knight wrote:
Nice and simple.
M Albeit, too simple.
M The above approach would basically remove the possibility to
M easily create bytes() from literals in Py3k, since literals in
M Py3k create Unicode objects,
Travis E. Oliphant wrote:
3) A new C-API function PyNumber_Index will be added with signature
Py_ssize_t PyNumber_index (PyObject *obj)
There's a typo in the function name here. Other than that, the PEP looks
pretty much fine to me.
About the only other quibble is that it could
We still need a release manager. No one has heard from Anthony.
It is the peak of the summer down here. Perhaps he is lucky enough
to be enjoying it away from computers for a while?
=Tony.Meyer
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
If bytes support the buffer interface, we get another interesting
issue -- regular expressions over bytes. Brr.
We already have that:
import re, array
re.search('\2', array.array('B', [1, 2, 3, 4])).group()
array('B', [2])
Not sure whether to blame array
Bob Ippolito wrote:
On Feb 14, 2006, at 4:17 PM, Guido van Rossum wrote:
(Why would you even think about views here? They are evil.)
I mention views because that's what numpy/Numeric/numarray/etc.
do... It's certainly convenient at times to have that functionality,
for example, to work
On Tue, 14 Feb 2006 12:31:07 -0700, Neil Schemenauer [EMAIL PROTECTED] wrote:
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
On Tue, Feb 14, 2006 at 09:32:09PM -0800, Bill Janssen wrote:
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
Greg Ewing wrote:
Brett Cannon wrote:
One protects us from ending up with an unusable AST since
the seralization can keep the original AST around and if the version
passed back in from Python code is junk it can be tossed and the
original version used.
I don't understand why this is an
On Tue, Feb 14, 2006 at 09:58:46PM -0800, Neal Norwitz wrote:
We need to ensure that PEPs 308, 328, and 343 are implemented. We
have possible volunteers for 308 and 343, but not 328. Brett is doing
352 and Martin is doing 353.
I can volunteer for 328 if no one else wants it, I've messed
Guido van Rossum wrote:
(Now that I work for Google I realize more than ever before the
importance of keeping URLs stable; PageRank(tm) numbers don't get
transferred as quickly as contents. I have this worry too in the
context of the python.org redesign; 301 permanent redirect is *not*
going
Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 07:28:36PM +1000, Nick Coghlan wrote:
On the 'unusable AST' front, if AST transformation code creates illegal
output, then the main thing is to raise an exception complaining about
what's wrong with it. I believe that may need a change to the
On Wed, 15 Feb 2006 00:34:35 -0800
Brett Cannon [EMAIL PROTECTED] wrote:
As per Neal's prodding email, here is a thread to discuss where we
want to go with the C AST to Python stuff and what I think are the
core issues at the moment.
First issue is the ast-objects branch. Work is being
Fred == Fred L Drake, [EMAIL PROTECTED] writes:
Fred 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
[Smith]
The following discussion ends with things that python-dev might want to
consider in terms of adding a function that allows something other than the
default 12- and 17-digit precision representations of numbers that str() and
repr() give. Such a function (like nice(), perhaps named
I've been thinking about generalization of the *args/**kwargs syntax for
quite a while, and even though I'm pretty sure Guido (and many people) will
consider it overgeneralization, I am finally going to suggest it. This whole
idea is not something dear to my heart, although I obviously would
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not* scattering files all over the place when
installing something.
MacOSX seems to be the only system so far that has
Thomas Wouters wrote:
On Tue, Feb 14, 2006 at 09:32:09PM -0800, Bill Janssen wrote:
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
I am still -1 on the ast-objects branch. It adds a lot of boilerplate
code and its makes complicated what is now simple. I'll see if I can
get a rough cut of the marshal code ready today, so there will be a
complete implementation of my original plan.
I also think we should keep the
On Wed, Feb 15, 2006, Thomas Wouters wrote:
I can volunteer for 328 if no one else wants it, I've messed with the import
mechanism before (and besides, it's fun.) I've also written an unfinished
308 implementation to get myself acquainted with the AST code more.
'Unfinished' means that it
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
A problem that I pointed out with the proposed areclose() function is that it
has within it a fp comparison. If such a function is to have greater utility,
it should allow the user to specify how significant to consider the computed
error. A natural extension of being able to tell if 2 fp
On Tue, 14 Feb 2006 15:14:07 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
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
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
On Wed, Feb 15, 2006 at 10:29:38AM -0500, Jeremy Hylton wrote:
Unfortunately, the compiler talk isn't until the last day and I can't
stay for sprints. It would be better to have the talk, then the open
space, then the sprint.
If you mean Implementation of the Python Bytecode Compiler, that's
On Wed, 2006-02-15 at 00:34 -0800, Brett Cannon wrote:
I personally think we should choose an initial global access API to
the AST as a starting API. I like the sys.ast_transformations idea
since it is simple and gives enough access that whether read-only or
read-write is allowed something
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 Tue, 2006-02-14 at 21:24 -0800, Neal Norwitz wrote:
We still need a release manager. No one has heard from Anthony. If
he isn't interested is someone else interested in trying their hand at
it? There are many changes necessary in PEP 101 because since the
last release both python and
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
On 2/14/06, Neil Schemenauer wrote:
People could spell it bytes(s.encode('latin-1'))
Guido wrote:
At the cost of an extra copying step.
I asked:
... why not just add some smarts to the bytes constructor?
Guido wrote:
... the VM usually keeps an extra reference
on the stack so the refcount
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
Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106])
It's
On 2/15/06, Jason Orendorff [EMAIL PROTECTED] wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash =
bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36,
[Bob Ippolito wrote]
...
/Library/Frameworks/Python.framework/...
/Applications/MacPython-2.4/... # just MacPython does this
ActivePython doesn't install app bundles for IDLE or anything?
It does, but puts them under here instead:
Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
I hope this will also be equivalent:
expected_md5_hash = bytes.from_hex('5c
Ron Adam [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
Ron Adam wrote:
b = bytes(0L) - bytes([0,0,0,0])
No, bytes(0L) -- TypeError because 0L doesn't implement
the iterator protocol or the buffer interface.
It wouldn't need it if it was a direct C memory copy.
Yes it would.
On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote:
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not* scattering files all over the place when
installing something.
Alain Poirier wrote:
- is (c)ElementTree still planned for inclusion ?
It is included already.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Thomas Wouters wrote:
I would personally prefer the AST validation to be a separate part of the
compiler. It means the one or the other can be out of sync, but it also
means it can be accessed directly (validating AST before sending it to the
compiler) and the compiler (or CFG generator, or
[Greg Ewing wrote]
It's not perfect, but it's still a lot better than the
situation on any other unix I've seen so far.
Better than Unix, sure. But you *can* (and ActivePython does do) install
everything under:
/opt/$app_name/...
open DMG, don't run the app from here, drag it to your
Jason Orendorff wrote:
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
This looks good, although it duplicates
expected_md5_hash = binascii.unhexlify('5c535024cac5199153e3834fe5c92e6a')
Regards,
Martin
___
Python-Dev mailing
On Tue, 14 Feb 2006 15:13:25 -0800, Guido van Rossum [EMAIL PROTECTED] 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
On 2/15/06, Tim Parkin [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
(Now that I work for Google I realize more than ever before the
importance of keeping URLs stable; PageRank(tm) numbers don't get
transferred as quickly as contents. I have this worry too in the
context of the
On 2/15/06, Thomas Wouters [EMAIL PROTECTED] wrote:
I've been thinking about generalization of the *args/**kwargs syntax for
quite a while, and even though I'm pretty sure Guido (and many people) will
consider it overgeneralization, I am finally going to suggest it. This whole
idea is not
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/)
Guido van Rossum wrote:
On 2/15/06, Tim Parkin [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I have this worry too in the
context of the python.org redesign; 301 permanent redirect is *not*
going to help PageRank of the new page.)
Could you expand on why 301 redirects won't help with the
As I said in an earlier message, there's no need to have a separate
domain to restrict queries to just the doc/current part of python.org.
Just type
site:python.org/doc/current your query here
If there isn't any other rationale, maybe we can redirects
docs.python.org back to www.python.org?
Jeremy Hylton wrote:
As I said in an earlier message, there's no need to have a separate
domain to restrict queries to just the doc/current part of python.org.
Just type
site:python.org/doc/current your query here
If there isn't any other rationale, maybe we can redirects
docs.python.org
On Tue, 14 Feb 2006 19:41:07 -0500, Raymond Hettinger [EMAIL PROTECTED]
wrote:
[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?
Georg Brandl wrote:
If something like Fredrik's new doc system is adopted, it would be extremely
convenient to refer someone to just
docs.python.org/os.path.join
without looking up how the page is actually named.
you could of course reserve a toplevel directory for that purpose; e.g.
Martin v. Löwis wrote:
- is (c)ElementTree still planned for inclusion ?
It is included already.
in the xml.etree package, in case someone's looking for it in the
usual place.
that is,
import xml.etree.ElementTree as ET
import xml.etree.cElementTree as ET
will work in any 2.5
Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227,
131,
On Wed, Feb 15, 2006 at 01:38:41PM -0500, Jim Jewett wrote:
On 2/14/06, Neil Schemenauer wrote:
People could spell it bytes(s.encode('latin-1'))
Guido wrote:
At the cost of an extra copying step.
I asked:
... why not just add some smarts to the bytes constructor?
Guido wrote:
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
Please, I don't much care about the fine points of the function's
semantics, but PLEASE rename that function to are_close. Every time I
see this subject in my email client I have to think for a few seconds
what the hell 'areclose' means. This time it's not just because of the
new PEP 8,
On Wed, 2006-02-15 at 14:01 -0500, Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(),
which works like this:
# two equivalent things
expected_md5_hash =
bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80,
Hi,
How bugfixes are handled?
I've posted a bug and a patch + test case for a quite common issue (see
google, problem mentioned on this ml) long time ago and nothing happened
with it
http://sourceforge.net/tracker/index.php?func=detailaid=1380952group_id=5470atid=305470
Is anyone reviewing
On 2/15/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Jason Orendorff wrote:
Also the pseudo-encodings ('hex', 'rot13',
'zip', 'uu', etc.) generally scare me.
Those are not pseudo-encodings, they are regular codecs.
It's a common misunderstanding that codecs are only seen as serving
the
Neal Norwitz wrote:
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
On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
Those are not pseudo-encodings, they are regular codecs.
It's a common misunderstanding that codecs are only seen as serving
the purpose of converting between Unicode and strings.
The codec system is deliberately designed to be
We're all volunteers here, and we get a large volume of bugs.
Unfortunately, bugfixes are reviewed on a voluntary basis.
Are you aware of the standing offer that if you review 5 bugs/patches
some of the developers will pay attention to your bug/patch?
On 2/15/06, Arkadiusz Miskiewicz [EMAIL
Georg Brandl wrote:
If something like Fredrik's new doc system is adopted
don't hold your breath, by the way. it's clear that the current PSF-sponsored
site overhaul won't lead to anything remotely close to a best-of-breed python-
powered site, and I'm beginning to think that I should spend my
Just in case you haven't noticed, I just merged
the ssize_t branch (PEP 353).
If you have any corrections to the code to make which
you would consider bug fixes, just go ahead.
If you are uncertain how specific problems should be resolved,
feel free to ask.
If you think certain API changes
Guido van Rossum wrote:
- it's probably too big to attempt to rush this into 2.5
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the
On Wed, Feb 15, 2006 at 11:28:59PM +0100, Fredrik Lundh wrote:
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the design can get
Thomas Wouters wrote:
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the design can get some real-world exposure in
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
Fredrik Lundh wrote:
Georg Brandl wrote:
If something like Fredrik's new doc system is adopted
don't hold your breath, by the way. it's clear that the current PSF-sponsored
site overhaul won't lead to anything remotely close to a best-of-breed python-
powered site, and I'm beginning to
Guido van Rossum [EMAIL PROTECTED] wrote:
Anyway, we need a new PEP author who can take the current
discussion and turn it into a coherent PEP.
I'm not sure that I have time to be the official champion. Right
now I'm spending some time to collect all the ideas presented in the
email messages
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
I'm actually assuming to put this off until 2.6 anyway.
On 2/15/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice
Great! I'll mark the PEP as accepted. (Which doesn't mean you can't
update it if changes are found necessary.)
--Guido
On 2/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Just in case you haven't noticed, I just merged
the ssize_t branch (PEP 353).
If you have any corrections to the code to
Ron Adam wrote:
I was presuming it would be done in C code and it will just need a
pointer to the first byte, memchr(), and then read n bytes directly into
a new memory range via memcpy().
If the object supports the buffer interface, it can be
done that way. But if not, it would seem to
Guido wrote:
I'm actually assuming to put this off until 2.6 anyway.
makes sense.
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
/F
___
Python-Dev mailing list
Python-Dev@python.org
Smith wrote:
The problem with areclose(), however, is that it
only solves one part of the problem that needs to be solved
if two fp's *are* going to be compared: if you are going to
check if a b you would need to do something like
not areclose(a,b) and a b
No, no, no.
If your
On Thu, 2006-02-16 at 01:09 +0100, Fredrik Lundh wrote:
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
We know at least there will never be a 2.10, so I think we still have
time.
-Barry
signature.asc
Description: This is a digitally signed message part
I'm in the process of summarizing the dicussion on the bytes object
and an idea just occured to me. Imagine that I want to write code
that deals with strings and I want to be maximally compatible with
P3k. It would be nice if I could add:
from __future__ import unicode_strings
and have
On Wed, 15 Feb 2006 15:20:16 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm actually assuming to put this off until 2.6 anyway.
On 2/15/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
After reading some of the discussion, and seen some of the arguments,
I'm
On Thu, Feb 16, 2006, Fredrik Lundh wrote:
Tim Parkin wrote:
[...]
no, you're not qualified. yet, someone gave you total control over the
future of python.org, and there's no way to make you give it up, despite
the fact that you're over a year late and the stuff you've delivered this
On Thu, 16 Feb 2006 00:36:35 + (UTC), Neil Schemenauer [EMAIL PROTECTED]
wrote:
I'm in the process of summarizing the dicussion on the bytes object
and an idea just occured to me. Imagine that I want to write code
that deals with strings and I want to be maximally compatible with
P3k. It
On 2/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
I'm in the process of summarizing the dicussion on the bytes object
and an idea just occured to me. Imagine that I want to write code
that deals with strings and I want to be maximally compatible with
P3k. It would be nice if I could add:
I don't think this message is on-topic for python-dev. There are lots
of great places to discuss the design of the python web site, but the
list for developers doesn't seem like a good place for it. Do we need
a different list for people to gripe^H^H^H^H^H discuss the web site?
Jeremy
On
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
from __future__ import unicode_strings
Didn't we have a command-line option to do this? I believe it was
removed because nobody could see the point. (Or am I hallucinating?
After several days of non-stop discussing bytes
Greg Ewing wrote:
I think you don't understand what an encoding is. Unicode
strings don't *have* an encoding, because theyre not encoded!
Encoding is what happens when you go from a unicode string
to something else.
Ah.. ok, my mental picture was a bit off. I had this reversed somewhat.
On Tue, Feb 14, 2006, Guido van Rossum wrote:
Anyway, I'm now convinced that bytes should act as an array of ints,
where the ints are restricted to range(0, 256) but have type int.
range(0, 255)?
--
Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/
19. A language that
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 Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
from __future__ import unicode_strings
Didn't we have a command-line option to do this? I believe it was
removed because nobody could see the point. (Or
On Feb 15, 2006, at 6:35 PM, Aahz wrote:
On Tue, Feb 14, 2006, Guido van Rossum wrote:
Anyway, I'm now convinced that bytes should act as an array of ints,
where the ints are restricted to range(0, 256) but have type int.
range(0, 255)?
No, Guido was correct. range(0, 256) is [0, 1, 2,
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP number.
Also, there are probably silly typos, etc. Sorry.
Neil
PEP: XXX
1 - 100 of 117 matches
Mail list logo
