Hi,
2011/5/18 Chris Withers ch...@simplistix.co.uk:
A friend of mine is coming over to Python and asked a question I thought
would have a better answer than it appears to:
How do I know which version of Python a PEP lands in?
I was expecting there to be a note at the bottom of the PEP, 342
That's great, but where is the list if changes?
--
anatoly t.
On Tue, May 17, 2011 at 9:50 PM, Georg Brandl ge...@python.org wrote:
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Python 3.2.1 will the first bugfix release for
Hi,
2011/5/18 anatoly techtonik techto...@gmail.com:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this file.
--
Amaury Forgeot d'Arc
___
How do I know which version of Python a PEP lands in?
You should look at the Python-Version header of the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 18.05.2011 07:39, Greg Ewing wrote:
Ethan Furman wrote:
On the one hand we have the 'bytes are ascii data' type interface, and
on the other we have the 'bytes are a list of integers between 0 - 256'
interface.
I think the weird part is that there exists a literal for
writing a byte
Is there code out there that is using this list of int's interface
Just in case this isn't clear yet: yes, certainly. Any non-trivial piece
of Python 3 code that has been written already (and there is some) will
have run into that issue.
Regards,
Martin
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this file.
I think it would be good if the release announcement made some
summary statement, though, like NNN bugs have been fixed, in MMM
2011/5/18 Martin v. Löwis mar...@v.loewis.de:
How do I know which version of Python a PEP lands in?
You should look at the Python-Version header of the PEP.
But some PEPs don't have it: 341, 342, 343, 353...
--
Amaury Forgeot d'Arc
___
Python-Dev
On Wed, May 18, 2011 at 4:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
How do I know which version of Python a PEP lands in?
You should look at the Python-Version header of the PEP.
Which is unfortunately missing from some PEPs (including PEP 342). PEP
344 shows where this information
On 18.05.2011 08:34, Martin v. Löwis wrote:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this file.
I think it would be good if the release announcement made some
summary statement,
On Wed, May 18, 2011 at 9:18 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hi,
2011/5/18 anatoly techtonik techto...@gmail.com:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this
On Wed, May 18, 2011 at 9:34 AM, Martin v. Löwis mar...@v.loewis.de wrote:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this file.
I think it would be good if the release announcement
On Wed, May 18, 2011 at 5:58 PM, anatoly techtonik techto...@gmail.com wrote:
On Wed, May 18, 2011 at 9:18 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hi,
2011/5/18 anatoly techtonik techto...@gmail.com:
That's great, but where is the list if changes?
All changes are always listed
On Wed, May 18, 2011 at 5:57 PM, Georg Brandl g.bra...@gmx.net wrote:
On 18.05.2011 08:34, Martin v. Löwis wrote:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download page displays this file.
I think it
On Wed, May 18, 2011 at 1:40 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 18, 2011 at 5:58 PM, anatoly techtonik techto...@gmail.com
wrote:
On Wed, May 18, 2011 at 9:18 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hi,
2011/5/18 anatoly techtonik techto...@gmail.com:
That's
On 18.05.2011 12:49, Nick Coghlan wrote:
On Wed, May 18, 2011 at 5:57 PM, Georg Brandl g.bra...@gmx.net wrote:
On 18.05.2011 08:34, Martin v. Löwis wrote:
That's great, but where is the list if changes?
All changes are always listed in the Misc/NEWS file.
A Change log link on every download
On Wed, May 18, 2011 at 8:58 PM, Georg Brandl g.bra...@gmx.net wrote:
On 18.05.2011 12:49, Nick Coghlan wrote:
Wishlist item: How hard would it be to run a ReST parser over
Misc/NEWS and create a HTML version for inclusion in the release
pages? (Bonus points if it steals the issue reference
On 18.05.2011 12:50, anatoly techtonik wrote:
On Wed, May 18, 2011 at 1:40 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 18, 2011 at 5:58 PM, anatoly techtonik techto...@gmail.com
wrote:
On Wed, May 18, 2011 at 9:18 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hi,
2011/5/18
On Wed, May 18, 2011 at 8:50 PM, anatoly techtonik techto...@gmail.com wrote:
I believe you misunderstood. If you follow what's new link above, you
will see a link to Misc/NEWS, but this one leads to
http://hg.python.org/cpython/file/default/Misc/NEWS where no
references to 3.2.1 are
Le mercredi 18 mai 2011 à 12:58 +0200, Georg Brandl a écrit :
On 18.05.2011 12:49, Nick Coghlan wrote:
On Wed, May 18, 2011 at 5:57 PM, Georg Brandl g.bra...@gmx.net wrote:
On 18.05.2011 08:34, Martin v. Löwis wrote:
That's great, but where is the list if changes?
All changes are always
On Wed, May 18, 2011 at 01:26:40PM +0200, Victor Stinner wrote:
http://dev.pocoo.org/~gbrandl/news.html
Oh, I like it. But the output should be reST to be able to include it
directly in the Python documentation. Sphinx would generate a new table
Interesting ideas! It would be really useful
On 18.05.2011 13:26, Victor Stinner wrote:
See
http://dev.pocoo.org/~gbrandl/news.html
which I made as an experiment a while ago.
Oh, I like it. But the output should be reST to be able to include it
directly in the Python documentation. Sphinx would generate a new table
of contents
Greetings,
While studying `virtualenv` code I've noticed that in Python directory
tree `include`, `libs` and `tcl` are lowercased while other dirs are
capitalized. It doesn't seem important (especially for developers
here), but it still can leave an unpleasant image for people new to
Python (and
Le mercredi 18 mai 2011 à 13:35 +0200, Georg Brandl a écrit :
On 18.05.2011 13:26, Victor Stinner wrote:
See
http://dev.pocoo.org/~gbrandl/news.html
which I made as an experiment a while ago.
Oh, I like it. But the output should be reST to be able to include it
directly in
On 18.05.2011 14:06, Victor Stinner wrote:
Le mercredi 18 mai 2011 à 13:35 +0200, Georg Brandl a écrit :
On 18.05.2011 13:26, Victor Stinner wrote:
See
http://dev.pocoo.org/~gbrandl/news.html
which I made as an experiment a while ago.
Oh, I like it. But the output should be
Hi,
''.join(c for c in 'abc') and ''.join([c for c in 'abc']) do create a
temporary c variable. In this case, the variable is useless and requires
two opcodes: STORE_FAST(c), LOAD_FAST(c). The variable is not available
outside the list comprehension/generator.
I would like to remove the variable
On May 18, 2011 7:03 AM, anatoly techtonik techto...@gmail.com wrote:
Greetings,
While studying `virtualenv` code I've noticed that in Python directory
tree `include`, `libs` and `tcl` are lowercased while other dirs are
capitalized. It doesn't seem important (especially for developers
2011/5/18 Victor Stinner victor.stin...@haypocalc.com:
Hi,
''.join(c for c in 'abc') and ''.join([c for c in 'abc']) do create a
temporary c variable. In this case, the variable is useless and requires
two opcodes: STORE_FAST(c), LOAD_FAST(c). The variable is not available
outside the list
On Wed, May 18, 2011 at 9:26 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Oh, I like it. But the output should be reST to be able to include it
directly in the Python documentation. Sphinx would generate a new table
of contents with links to each release.
As Georg noted, Misc/NEWS
It's time to continue 2.7.* point releases with 2.7.2 and finish off
3.1.* with 3.1.4. I plan to do a RC for both on May 28th and a final
on June 11th.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
On Wed, May 18, 2011 at 10:21 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
What do you think? Is it useless and/or stupid?
I wouldn't call it useless or stupid - merely lost in the noise. In
small cases, I expect it would be swamped completely by the high fixed
overhead of entering the
On Wed, May 18, 2011 at 2:21 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
''.join(c for c in 'abc') and ''.join([c for c in 'abc']) do create a
temporary c variable.
I'm not sure why you would encounter code like that in the first place.
Surely any code of the form:
''.join(c for
Georg Brandl g.bra...@gmx.net wrote:
We do have
bytes.fromhex('deadbeef')
Sort of reminds me of Java's Integer.parseInt(), and not in a good way.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
Ethan Furman wrote:
On the one hand we have the 'bytes are ascii data' type interface, and
on the other we have the 'bytes are a list of integers between 0 -
255' interface.
I think the weird part is that there exists a literal for
writing a byte array as an ascii string,
Robert Collins writes:
Its probably too late to change, but please don't try to argue that
its correct: the continued confusion of folk running into this is
evidence that confusion *is happening*. Treat that as evidence and
think about how to fix it going forward.
Sorry, Rob, but you're
Hi,
http://hg.python.org/cpython/rev/c83fb59b73ea
user:Vinay Sajip vinay_sa...@yahoo.co.uk
date:Tue May 17 07:15:53 2011 +0100
summary:
Skip some more tests in the absence of threading
diff --git a/Lib/test/test_logging.py b/Lib/test/test_logging.py
---
Hi again,
http://hg.python.org/cpython/rev/4b7c29201c60
user:Vinay Sajip vinay_sa...@yahoo.co.uk
summary:
Skip some tests in the absence of multiprocessing.
+@unittest.skipUnless(threading, 'Threading required for this test.')
Who wins, the commit message or the code? :)
+
On Thu, 19 May 2011 01:16:44 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
Robert Collins writes:
Its probably too late to change, but please don't try to argue that
its correct: the continued confusion of folk running into this is
evidence that confusion *is happening*. Treat
Le 17/05/2011 18:42, Christian Heimes a écrit :
A good place for a local sysconfig.cfg could be the user's stdlib
directory (e.g. ~/.local/lib/python3.2/sysconfig.cfg).
I don’t think so. See http://bugs.python.org/issue7175 and
I fixed recently some bugs in distutils. Should I also fix them in the
packaging module, or are both modules already synchronized?
I ported some fixes, especially in sysconfig; for distutils, I have a
number of them marked for backport in the bug tracker (distutils2
component) or in personal
In Python 3 inequality comparisons became forbidden.
-- 123 [1, 2, 3]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unorderable types: int() list()
However, equality comparisons are still allowed
-- 123 == [1, 2, 3]
False
But you can't mix them (inequality
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Shouldn't there be a tag v3.2.1rc1 in the hg repo?
Cheers,
Hagen
___
Python-Dev mailing list
Python-Dev@python.org
Am 18.05.2011 08:38, schrieb Amaury Forgeot d'Arc:
2011/5/18 Martin v. Löwis mar...@v.loewis.de:
How do I know which version of Python a PEP lands in?
You should look at the Python-Version header of the PEP.
But some PEPs don't have it: 341, 342, 343, 353...
In these cases, the respective
Note that the more common idiom (not that I can measure it, mind)
when dealing with byte strings is something analogous to
if my_byte_string[i:i+1] == b'x':
rather than
if my_byte_string[i] == 170:
FWIW, Another spelling of this is
if my_byte_string[i] == ord(b'x')
From
Am 18.05.2011 20:39, schrieb Hagen Fürstenau:
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Shouldn't there be a tag v3.2.1rc1 in the hg repo?
http://hg.python.org/releasing/3.2.1/
Regards,
Martin
P.S. Shouldn't makes it
On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote:
Robert Collins writes:
Its probably too late to change, but please don't try to argue that
its correct: the continued confusion of folk running into this is
evidence that confusion *is happening*. Treat that as evidence and
think
Ethan Furman wrote:
Greg Ewing wrote:
As for
-- some_other_var[3] == b'd'
there ought to be a literal for specifying an integer
using an ascii character, so you could say something like
if some_other_var[3] == c'd':
which would be equivalent to
if some_other_var[3] == ord(b'd')
but
2011/5/18 Ethan Furman et...@stoneleaf.us:
In Python 3 inequality comparisons became forbidden.
-- 123 [1, 2, 3]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unorderable types: int() list()
However, equality comparisons are still allowed
-- 123 == [1, 2,
P.S. Shouldn't makes it sound as if there was a mistake.
Well, I thought there was. When do these tags get merged into cpython
then? v3.2.1b1 is there, but v3.2.1rc1 isn't:
http://hg.python.org/cpython/tags
Cheers,
Hagen
___
Python-Dev mailing list
On 18.05.2011 21:09, Martin v. Löwis wrote:
Am 18.05.2011 20:39, schrieb Hagen Fürstenau:
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Shouldn't there be a tag v3.2.1rc1 in the hg repo?
On 18.05.2011 21:06, Martin v. Löwis wrote:
Note that the more common idiom (not that I can measure it, mind)
when dealing with byte strings is something analogous to
if my_byte_string[i:i+1] == b'x':
rather than
if my_byte_string[i] == 170:
FWIW, Another spelling of this is
Ethan Furman wrote:
[...]
Also posted to Python-Ideas.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Am 18.05.2011 21:37, schrieb Hagen Fürstenau:
P.S. Shouldn't makes it sound as if there was a mistake.
Well, I thought there was. When do these tags get merged into cpython
then?
See PEP 101
Regards,
Martin
___
Python-Dev mailing list
Here's another thought, that perhaps is not backwards-incompatible...
some_var[3] == b'd'
At some point, the bytes class' __eq__ will be called -- is there a
reason why we cannot have
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the other object is an
Politely ask them to add it.
(just my suggrestion).
Laura
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Martin v. Löwis wrote:
Here's another thought, that perhaps is not backwards-incompatible...
some_var[3] == b'd'
At some point, the bytes class' __eq__ will be called -- is there a
reason why we cannot have
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the
On 5/18/2011 4:10 PM, Ethan Furman wrote:
Ethan Furman wrote:
[...]
Also posted to Python-Ideas.
Good. That is where it should have gone in the first place, as this is
about ideas not yet even in the PEP stage.
--
Terry Jan Reedy
___
Python-Dev
On 5/18/2011 2:51 PM, Ethan Furman wrote:
In Python 3 inequality comparisons became forbidden.
-- 123 [1, 2, 3]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unorderable types: int() list()
However, equality comparisons are still allowed
-- 123 == [1, 2, 3]
On 5/18/2011 10:19 AM, Nadeem Vawda wrote:
I'm not sure why you would encounter code like that in the first place.
Surely any code of the form:
''.join(c for c in my_string)
would just return my_string? Or am I missing something?
Good question. Anything useful like '-'.join(c for c in
Terry Reedy wrote:
On 5/18/2011 2:51 PM, Ethan Furman wrote:
In Python 3 inequality comparisons became forbidden.
-- 123 [1, 2, 3]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unorderable types: int() list()
However, equality comparisons are still allowed
--
Le mercredi 18 mai 2011 à 16:19 +0200, Nadeem Vawda a écrit :
I'm not sure why you would encounter code like that in the first place.
Well, I found the STORE_FAST/LOAD_FAST issue while trying to optimize
the this module which reimplements rot13 using a dict in Python 3:
d = {}
for c in (65,
Hi,
2011/5/18 Terry Reedy tjre...@udel.edu:
On 5/18/2011 10:19 AM, Nadeem Vawda wrote:
I'm not sure why you would encounter code like that in the first place.
Surely any code of the form:
''.join(c for c in my_string)
would just return my_string? Or am I missing something?
Good
Immutable objects that compare equal should hash equal;
so we would also have to change the hashing of byte strings. Not sure
whether that, in turn, has undesirable consequences.
I thought it was the other-way-round -- if they hash equal, they should
compare equal?
No no no. If they hash
Georg Brandl wrote:
We do have
bytes.fromhex('deadbeef')
But again, there is a run-time overhead to this.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Eric Smith wrote:
And of course it's too late to make any change to this.
It's too late to change the meaning of b'...', but is it
really too late to introduce an x'...' literal and change
the repr() to produce it?
--
Greg
___
Python-Dev mailing
Ethan Furman wrote:
some_var[3] == b'd'
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the other object is an int, and
2) 0 = other_obj 256
3) if 1 and 2, make the comparison instead of returning NotImplemented?
It might seem convenient, but I'd worry that
On 5/18/2011 6:32 PM, Greg Ewing wrote:
Eric Smith wrote:
And of course it's too late to make any change to this.
It's too late to change the meaning of b'...', but is it
really too late to introduce an x'...' literal and change
the repr() to produce it?
My this was the different types
Victor Stinner wrote:
squares = (x*x for x in range(1))
What bytecode would you optimise that into?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, May 19, 2011 at 4:16 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Robert Collins writes:
Its probably too late to change, but please don't try to argue that
its correct: the continued confusion of folk running into this is
evidence that confusion *is happening*. Treat that
On 5/18/2011 5:34 PM, Victor Stinner wrote:
You initial example gave me the impression that the issue has something
to do with join in particular, or even comprehensions in particular. It
is really about for loops.
squares = (x*x for x in range(1))
dis('for x in range(3): y =
On 5/18/2011 5:37 PM, Amaury Forgeot d'Arc wrote:
Hi,
2011/5/18 Terry Reedytjre...@udel.edu:
On 5/18/2011 10:19 AM, Nadeem Vawda wrote:
I'm not sure why you would encounter code like that in the first place.
Surely any code of the form:
''.join(c for c in my_string)
would just return
On Wed, May 18, 2011 at 3:47 PM, Brian Curtin brian.cur...@gmail.com wrote:
On May 18, 2011 7:03 AM, anatoly techtonik techto...@gmail.com wrote:
Greetings,
While studying `virtualenv` code I've noticed that in Python directory
tree `include`, `libs` and `tcl` are lowercased while other
On Wed, May 18, 2011 at 10:37 PM, Georg Brandl g.bra...@gmx.net wrote:
On 18.05.2011 21:09, Martin v. Löwis wrote:
Am 18.05.2011 20:39, schrieb Hagen Fürstenau:
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Shouldn't there be
On Wed, May 18, 2011 at 21:33, anatoly techtonik techto...@gmail.comwrote:
On Wed, May 18, 2011 at 3:47 PM, Brian Curtin brian.cur...@gmail.com
wrote:
On May 18, 2011 7:03 AM, anatoly techtonik techto...@gmail.com
wrote:
Greetings,
While studying `virtualenv` code I've noticed that
On 5/18/2011 10:33 PM, anatoly techtonik wrote:
├[Python27]
│ ├─DLLs
│ ├─Doc
│ ├─include
│ ├─Lib
│ ├─libs
│ ├─Scripts
│ ├─tcl
│ └─Tools
Except for DLLs and tcl, these are the platform-independent names in the
source tree. They are copied directly over to the installations, and I
would not
On 5/18/2011 10:46 PM, anatoly techtonik wrote:
On Wed, May 18, 2011 at 10:37 PM, Georg Brandlg.bra...@gmx.net wrote:
On 18.05.2011 21:09, Martin v. Löwis wrote:
http://hg.python.org/releasing/3.2.1/
To clarify: once the final is done, the repo Martin mentioned will be
merged back to
Can't this work be done in the branch of main repo, so that everybody
can track the progress in place? Is there any picture of the process
similar to http://nvie.com/posts/a-successful-git-branching-model/ ?
It *is* a branch of the main repo, so everybody *can* track the progress
(not sure
On 19.05.2011 00:39, Greg Ewing wrote:
Ethan Furman wrote:
some_var[3] == b'd'
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the other object is an int, and
2) 0 = other_obj 256
3) if 1 and 2, make the comparison instead of returning NotImplemented?
On 18.05.2011 21:37, Hagen Fürstenau wrote:
P.S. Shouldn't makes it sound as if there was a mistake.
Well, I thought there was. When do these tags get merged into cpython
then? v3.2.1b1 is there, but v3.2.1rc1 isn't:
http://hg.python.org/cpython/tags
3.2.1b1 was already merged back. (And
79 matches
Mail list logo
