Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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 in this case, but that doesn't appear to be the case. What is the policy on this? Where should we be looking? Normally PEPs are important enough to be mentioned in the whatsnew document of each release. Googling for what's new pep 342 suggests that it was released with Python 2.5. Now, an official way to get this information would probably be better... -- Amaury Forgeot d'Arc ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a testing release: Please consider trying Python 3.2.1 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) ___ 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/techtonik%40gmail.com ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 ___ 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
Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
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 array as an ascii string, and furthermore
that it's the *only* kind of literal available for bytes.
Personally I think that the default literal syntax for
bytes, and also the form produced by repr(), should have
been something more neutral, such as hex, with the ascii
form available for use when it makes sense. Currently if
you want to write a bytes literal in hex, you have to
say something like
some_var = b'\xde\xad\xbe\xef'
which is ugly and unreadable. Much nicer would be
some_var = x'deadbeef'
We do have
bytes.fromhex('deadbeef')
Georg
___
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
Re: [Python-Dev] Python 3.x and bytes
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 ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 modules; see NEWS for details, or some such. Regards, Martin ___ 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
Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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 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
Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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 *should* be, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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, though, like NNN bugs have been fixed, in MMM modules; see NEWS for details, or some such. It does say over NNN bugs have been fixed, not sure if the MMM modules add anything of value. I agree that a link to the NEWS file should be present though. Georg ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 file. I actually followed http://docs.python.org/3.2/whatsnew/3.2.html to Misc/NEWS, but it doesn't contain any references of 3.2.1 -- anatoly t. ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 made some summary statement, though, like NNN bugs have been fixed, in MMM modules; see NEWS for details, or some such. That's a good idea. But for such kind of query Roundup should be module aware [1,2]. I'd say if Jesse could make a competition on best announcement format - we could easily see what information we tend to skip while preparing the releases (and improve NEWS format [3]). [1] http://code.google.com/p/pydotorg/issues/detail?id=8 [2] http://psf.upfronthosting.co.za/roundup/meta/issue373 [3] https://convore.com/the-changelog/the-best-changelog/ -- anatoly t. ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 in the Misc/NEWS file. A Change log link on every download page displays this file. I actually followed http://docs.python.org/3.2/whatsnew/3.2.html to Misc/NEWS, but it doesn't contain any references of 3.2.1 What's New and Misc/NEWS are not the same thing. Misc/NEWS is the second info link on the download page (Change log for this release). (In this case, it lands at http://hg.python.org/releasing/3.2.1/file/v3.2.1rc1/Misc/NEWS) Agreed that What's New isn't a hugely useful thing to link from a point release announcement, though. It sounds like Georg is going to change that for the actual release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 would be good if the release announcement made some summary statement, though, like NNN bugs have been fixed, in MMM modules; see NEWS for details, or some such. It does say over NNN bugs have been fixed, not sure if the MMM modules add anything of value. I agree that a link to the NEWS file should be present though. 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 linkification code from the tracker...) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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 actually followed http://docs.python.org/3.2/whatsnew/3.2.html to Misc/NEWS, but it doesn't contain any references of 3.2.1 What's New and Misc/NEWS are not the same thing. 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 available. Agreed that What's New isn't a hugely useful thing to link from a point release announcement, though. It sounds like Georg is going to change that for the actual release. There is nothing bad in linking to major release notes (i.e. What's New). IIRC, Mozilla does that for their minor releases, but they explicitly mention changes since last minor release. -- anatoly t. ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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 modules; see NEWS for details, or some such. It does say over NNN bugs have been fixed, not sure if the MMM modules add anything of value. I agree that a link to the NEWS file should be present though. 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 linkification code from the tracker...) See http://dev.pocoo.org/~gbrandl/news.html which I made as an experiment a while ago. Georg ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 linkification code from the tracker...) See http://dev.pocoo.org/~gbrandl/news.html which I made as an experiment a while ago. I quite like that! What would we need to do to make it part of the docs build process? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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. I actually followed http://docs.python.org/3.2/whatsnew/3.2.html to Misc/NEWS, but it doesn't contain any references of 3.2.1 What's New and Misc/NEWS are not the same thing. 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 available. This link is wrong, it should point to /cpython/file/3.2/Misc/NEWS. (But you'll still not see 3.2.1 changes until the 3.2.1 final release, because the rc is made from a separate clone.) Georg ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 available. Ah, I see what you mean. That actually looks to be a bug in the :source: tag that generates the file links. It should really generate version appropriate links, but it currently just always links to default. (This wasn't an issue until 3.2 was released and 3.3 development started. Older versions didn't have that tag, and hence referenced the specific release directly). The source code links in the module docs have the same problem (e.g. see http://docs.python.org/3.2/library/functools) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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 modules; see NEWS for details, or some such. It does say over NNN bugs have been fixed, not sure if the MMM modules add anything of value. I agree that a link to the NEWS file should be present though. 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 linkification code from the tracker...) 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 with links to each release. Victor ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 too. +1 -- Senthil ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 with links to each release. The output of processing reST should be reST? Now I'm confused. Georg ___ 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
[Python-Dev] Inconsistent case in directory names for installed Python on Windows
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 programming in general). ├[Python27] │ ├─DLLs │ ├─Doc │ ├─include │ ├─Lib │ ├─libs │ ├─Scripts │ ├─tcl │ └─Tools How about making a consistent lowercased or uppercased scheme? Windows filesystems are case-insensitive, so the change shouldn't affect anybody. Another candidate for normalization is Tools/Scripts dir, which I'd lowercase FWIW: └─Tools ├─i18n ├─pynche ├─Scripts ├─versioncheck └─webchecker Lowercased dirs on a top level seem to contains files that are relevant to C developers only. However, I can not say for sure. It seems that there could be a better place for them like top level directory named Dev or C-API. -- anatoly t. ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 the Python documentation. Sphinx would generate a new table of contents with links to each release. The output of processing reST should be reST? Now I'm confused. Misc/NEWS is already formatted to reST? It doesn't contain any link (to the issues). We may replace Issue #xxx by :issue:`xxx` (directly in Misc/NEWS) to simplify the process? And maybe move Misc/NEWS to Doc? http://dev.pocoo.org/~gbrandl/news.html is an HTML document. Victor ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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. The output of processing reST should be reST? Now I'm confused. Misc/NEWS is already formatted to reST? Yes, it is. It doesn't contain any link (to the issues). We may replace Issue #xxx by :issue:`xxx` (directly in Misc/NEWS) to simplify the process? Replacing the issue links is the only preprocessing that I did. And maybe move Misc/NEWS to Doc? I don't think people would like that :) http://dev.pocoo.org/~gbrandl/news.html is an HTML document. As the file name says :) Georg ___ 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
[Python-Dev] Don't set local variable in a list comprehension or generator
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 in these cases to speed up (micro-optimize!) Python. Remove the variable breaks code using introspection like: list([locals()['x'] for x in range(3)]) We may detect the usage of introspection (I don't know how hard it is), only optimize trivial cases (like x for x in ...), or only optmize with Python is running in optimize mode (python -O or python -OO). What do you think? Is it useless and/or stupid? I heard about optimization in the AST tree instead of working on the bytecode. What is the status of this project? Victor ___ 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
Re: [Python-Dev] Inconsistent case in directory names for installed Python on Windows
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 here), but it still can leave an unpleasant image for people new to Python (and programming in general). In theory there are probably a lot of things that might seem unpleasant but are actually non-issues. I don't believe there have been any complaints about actual unpleasantries with directory case. ├[Python27] │ ├─DLLs │ ├─Doc │ ├─include │ ├─Lib │ ├─libs │ ├─Scripts │ ├─tcl │ └─Tools How about making a consistent lowercased or uppercased scheme? Windows filesystems are case-insensitive, so the change shouldn't affect anybody. Some Macs have case-sensitive file systems, and some people use case-sensitive file systems on various flavors of UNIX. The change would probably require a thorough look through the build chain. Another candidate for normalization is Tools/Scripts dir, which I'd lowercase FWIW: └─Tools ├─i18n ├─pynche ├─Scripts ├─versioncheck └─webchecker Lowercased dirs on a top level seem to contains files that are relevant to C developers only. However, I can not say for sure. It seems that there could be a better place for them like top level directory named Dev or C-API. -- anatoly t. Overall I think it boils down to a cosmetic change that I'm not sure we need to make, which could unnecessarily break people's work. -1 ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 comprehension/generator. I would like to remove the variable in these cases to speed up (micro-optimize!) Python. Remove the variable breaks code using introspection like: list([locals()['x'] for x in range(3)]) We may detect the usage of introspection (I don't know how hard it is), only optimize trivial cases (like x for x in ...), or only optmize with Python is running in optimize mode (python -O or python -OO). What do you think? Is it useless and/or stupid? Far more useful would be figuring out how to remove the call. -- Regards, Benjamin ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 is already ReST. My proposal was essentially to add an extra step to the docs build process that invoked the same commands that Georg used to generate the sample version (with appropriate additions to Doc/tools as needed to make that work). The generated NEWS.html file could easily live inside the whatsnew directory alongside the actual What's New document. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] 2.7.2 and 3.1.4
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 new scope and in all generator expressions I expected it would be swamped by the cost of resuming the generator on each iteration, and even for comprehensions any time spent on the unneeded variable assignment is likely still going to be dominated by the __next__() call overhead. I heard about optimization in the AST tree instead of working on the bytecode. What is the status of this project? First step is getting back to Eugene Toder's AST cleanup patch and working on getting that in. It's a big patch though, and I'd like to see it broken up into a couple of distinct phases before we proceed. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 c in my_string) would just return my_string? Or am I missing something? I heard about optimization in the AST tree instead of working on the bytecode. What is the status of this project? Are you referring to issue11549? There was some related discussion [1] on python-dev about six weeks ago, but I haven't seen anything on the topic since then. Cheers, Nadeem [1] http://mail.python.org/pipermail/python-dev/2011-April/110399.html ___ 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
Re: [Python-Dev] Python 3.x and bytes
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
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
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, and furthermore that it's the *only* kind of literal available for bytes. That is the point I was trying to make -- thank you for stating it more clearly than I managed to. :) Personally I think that the default literal syntax for bytes, and also the form produced by repr(), should have been something more neutral, such as hex, Agreed. It is surprising to extract an element out of bytes, and not end up with bytes, but with an int -- if the repr used something besides the plain ascii representation, this would not be an expectation. For comparison, when one extracts an element out of a str one gets a str -- not the int representing the unicode code point. with the ascii form available for use when it makes sense. 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 without the overhead of computing the value each time at run time. Given that we can't change the behavior of b'abc'[1], that would be better than what we have. +1 ~Ethan~ ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 just wrong here, and Nick is right. It's possible to improve Python 3, but not to fix it in this respect. The Python 3 solution is correct, the Python 2 approach is not. There's no way to avoid discontinuity and confusion here. Confusion is indeed happening, but it's real confusion in the way people think about the problem space, not a language design cockup. The problem can't be solved by embedding ASCII in Unicode, because non-ASCII bytes don't have a canonical embedding in Unicode. Ie, the situation is inherently confusing. You can't wish it away, you can only choose to impose more or less of it on particular constituencies. Now, it's quite possible that there are other correct approaches that allow straightforward manipulation of non-ASCII text, but I don't know what they are, and I don't know anybody else who does. ___ 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
Re: [Python-Dev] [Python-checkins] cpython: Skip some more tests in the absence of threading.
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 --- a/Lib/test/test_logging.py +++ b/Lib/test/test_logging.py try: import threading +# The following imports are needed only for tests which +import asynchat I guess “for tests which use threading” +if threading: +class TestSMTPChannel(smtpd.SMTPChannel): I wonder if you could have saved yourself all this reindenting if your import had fallen back to dummy_threading. +@unittest.skipUnless(threading, 'Threading required for this test.') I’d have used lower-case threading, to make it a bit clearer that it’s the threading module that’s require, not some abstract notion of threading. But they may be the same thing, I’m not sure. Regards ___ 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
Re: [Python-Dev] [Python-checkins] cpython: Skip some tests in the absence of multiprocessing.
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? :)
+try:
+import multiprocessing as mp
+r = logging.makeLogRecord({})
+self.assertEqual(r.processName, mp.current_process().name)
+except ImportError:
+pass
Isn’t support.import_module or somesuch useful for this kind of checks?
Regards
___
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
Re: [Python-Dev] Python 3.x and bytes
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 that as evidence and think about how to fix it going forward. Sorry, Rob, but you're just wrong here, and Nick is right. It's possible to improve Python 3, but not to fix it in this respect. The Python 3 solution is correct, the Python 2 approach is not. There's no way to avoid discontinuity and confusion here. Confusion is indeed happening, but it's real confusion in the way people think about the problem space, not a language design cockup. 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: and the former is a lot more readable than the latter, even though you have to stare at the slice for a couple seconds the first time you encounter it to realize what is going on. So *something* is wrong with Python3's approach. Python2 was wronger, though :) --David ___ 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
Re: [Python-Dev] packaging merge imminent
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 http://mail.python.org/pipermail/python-dev/2010-August/103011.html Regards ___ 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
Re: [Python-Dev] packaging merge imminent
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 bookmarks. There are not very many. Cheers ___ 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
[Python-Dev] Equality testing
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 wins) -- 123 = [1, 2, 3] Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() = list() I realize this is probably a Py4000 change if it happens at all, but does this make sense? Shouldn't an attempt to compare to unlike objects be a TypeError, just like trying to order them is? It bit me when I tried to compare a byte string element with a single character byte string (of course they should have matched, but since the element was an int, the match was not longer True). ~Ethan~ ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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 authors (or somebody else who cares) should add it. Regards, Martin ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 a readability point, it's in the same category as the first one, but less twisted. Regards, Martin ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 sound as if there was a mistake. ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 about how to fix it going forward. Sorry, Rob, but you're just wrong here, and Nick is right. It's possible to improve Python 3, but not to fix it in this respect. The Python 3 solution is correct, the Python 2 approach is not. There's no way to avoid discontinuity and confusion here. I don't think there's any connection between the way 2.x confused text strings and binary data (which certainly needed addressing) with the way that 3.x returns a different type for byte_str[i] than it does for byte_str[i:i+1]. I think it's the latter that's confusing to people. There's no particular requirement for different types that's needed to fix the byte/str problem. And of course it's too late to make any change to this. Eric. ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 without the overhead of computing the value each time at run time. Given that we can't change the behavior of b'abc'[1], that would be better than what we have. +1 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 int, and 2) 0 = other_obj 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? This makes sense to me -- after all, the bytes class is an array of ints in range(256); it is a special case, but doesn't feel any more special than passing an int into bytes() giving a string of that many null bytes; and it would get rid of the, in my opinion ugly, idiom of some_var[i:i+1] == b'd' It would also not require a new literal syntax. ~Ethan~ ___ 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
Re: [Python-Dev] Equality testing
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, 3] False But you can't mix them (inequality wins) -- 123 = [1, 2, 3] Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() = list() I realize this is probably a Py4000 change if it happens at all, but does this make sense? Shouldn't an attempt to compare to unlike objects be a TypeError, just like trying to order them is? No. Ordering for types which completely different doesn't make any sense, but equality testing is just fine because it has an obvious answer: no. -- Regards, Benjamin ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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? http://hg.python.org/releasing/3.2.1/ Regards, Martin P.S. Shouldn't makes it sound as if there was a mistake. To clarify: once the final is done, the repo Martin mentioned will be merged back to main and then vanish. Georg ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 if my_byte_string[i] == ord(b'x') From a readability point, it's in the same category as the first one, but less twisted. Probably more twisted: if my_byte_string[i] == b'x'[0]: :) Georg ___ 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
Re: [Python-Dev] Python 3.x and bytes
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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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
Re: [Python-Dev] Python 3.x and bytes
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 int, and 2) 0 = other_obj 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? 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. In addition, equality should be transitive, so b'A' == 65.0. Regards, Martin ___ 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
Re: [Python-Dev] how do you find out what version of Python a PEP landed in?
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
Re: [Python-Dev] Python 3.x and bytes
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 other object is an int, and 2) 0 = other_obj 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? 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? Or is this just for immutables? In addition, equality should be transitive, so b'A' == 65.0. I'm not sure what you're getting at... we could certainly have step 2 check for a number instead of an int, and then step 3 could extract the one element, giving an int, and then let that int compare itself with the other number, whether it be int, float, fraction, what-have-you. ~Ethan~ ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 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
Re: [Python-Dev] Equality testing
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] False But you can't mix them (inequality wins) -- 123 = [1, 2, 3] Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() = list() I realize this is probably a Py4000 change if it happens at all, but does this make sense? Shouldn't an attempt to compare to unlike objects be a TypeError, just like trying to order them is? It bit me when I tried to compare a byte string element with a single character byte string (of course they should have matched, but since the element was an int, the match was not longer True). Questions/comments like this that are not about developing the next versions of Python, as you acknowledge above, really belong elsewhere, like on the ideas list. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 'abc') is the
same as '-'.join('abc'). The same, as far as I can think of, for
anything like list() or set() taking an iterable arg.
--
Terry Jan Reedy
___
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
Re: [Python-Dev] Equality testing
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 -- 123 == [1, 2, 3] False But you can't mix them (inequality wins) -- 123 = [1, 2, 3] Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() = list() I realize this is probably a Py4000 change if it happens at all, but does this make sense? Shouldn't an attempt to compare to unlike objects be a TypeError, just like trying to order them is? It bit me when I tried to compare a byte string element with a single character byte string (of course they should have matched, but since the element was an int, the match was not longer True). Questions/comments like this that are not about developing the next versions of Python, as you acknowledge above, really belong elsewhere, like on the ideas list. My apologies. I'll be more careful. ~Ethan~ ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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, 97):
for i in range(26):
d[chr(i+c)] = chr((i+13) % 26 + c)
I tried:
d = {chr(i+c): chr((i+13) % 26 + c)
for i in range(26)
for c in (65, 97)}
But it is slower whereas I read somewhere than generators are faster
than loops. By the way, (c for c in ...) is slower than [c for c
in ...]. I suppose that a generator is slower because it exits/reenter
into PyEval_EvalFrameEx() at each step, whereas [c for c ...] uses
BUILD_LIST in a dummy (but fast) loop.
(c for c in ...) and [c for c in ...] is stupid, but I used a simplified
example to explain the problem. A more realistic example would be:
squares = (x*x for x in range(1))
You don't really need the x variable, you just want the square.
Another example is the syntax using a if the filter the data set:
(x for x in ... if condition(x))
I heard about optimization in the AST tree instead of working on the
bytecode. What is the status of this project?
Are you referring to issue11549? There was some related discussion [1] on
python-dev about six weeks ago, but I haven't seen anything on the topic
since then.
Ah yes, it looks to be this issue. I didn't know that there was an
issue.
Victor
___
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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 question. Anything useful like '-'.join(c for c in 'abc') is the same
as '-'.join('abc'). The same, as far as I can think of, for anything like
list() or set() taking an iterable arg.
With a little imagination you can build something non trivial.
For example, a join_words function:
def join_words(words):
return ', '.join(w.strip() for w in words)
Like Victor says, the code of the generator object contains a
STORE_FAST followed by LOAD_FAST.
This pair of opcodes could be removed, and the value left on the stack.
dis.dis(join_words.func_code.co_consts[2])
1 0 SETUP_LOOP 24 (to 27)
3 LOAD_FAST0 (.0)
6 FOR_ITER17 (to 26)
9 STORE_FAST 1 (w)
12 LOAD_FAST1 (w)
15 LOAD_ATTR0 (strip)
18 CALL_FUNCTION0
21 YIELD_VALUE
22 POP_TOP
23 JUMP_ABSOLUTE6
26 POP_BLOCK
27 LOAD_CONST 0 (None)
30 RETURN_VALUE
It's probably not easy to do though.
Think of expressions where the variable appears several times,
or even where the variable is not the first object, like str(ord(x)).
--
Amaury Forgeot d'Arc
___
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
Re: [Python-Dev] Python 3.x and bytes
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 equal, it could just be a hash collision - objects of a class could all hash to 42, if they wanted to. Dictionaries require the property I mentioned. If they compare equal, but hash differently, a dictionary lookup would fail to find the key. In addition, equality should be transitive, so b'A' == 65.0. I'm not sure what you're getting at... That it is counter-intuitive to have a bytes object compare equal to a floating-point number. Regards, Martin ___ 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
Re: [Python-Dev] Python 3.x and bytes
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:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
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 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
Re: [Python-Dev] Python 3.x and bytes
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 it would lead to even more confusion in other ways. If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is also true, they might expect to be able to do things like n = b'd' + 1 and get 101... or maybe b'e'... -- Greg ___ 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
Re: [Python-Dev] Python 3.x and bytes
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 returned by b[i] and b[i:i+1]. Eric. ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
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 as evidence and think about how to fix it going forward. Sorry, Rob, but you're just wrong here, and Nick is right. It's possible to improve Python 3, but not to fix it in this respect. The Python 3 solution is correct, the Python 2 approach is not. There's no way to avoid discontinuity and confusion here. The top level description: 'bytes is a different type to text[unicode] and casting between them must be explicit' is completely correct in Python 3: I didn't (and have never AFAIK) quibbled about that. Thats separate to the implementation issues I have mentioned in this thread and previous. Arguing that implicit casting is a good idea isn't what I was doing, nor what Nick was rebutting, AFAICT. -Rob ___ 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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 = x*x')
1 0 SETUP_LOOP 30 (to 33)
3 LOAD_NAME0 (range)
6 LOAD_CONST 0 (3)
9 CALL_FUNCTION1
12 GET_ITER
13 FOR_ITER16 (to 32)
16 STORE_NAME 1 (x)
19 LOAD_NAME1 (x)
22 LOAD_NAME1 (x)
25 BINARY_MULTIPLY
26 STORE_NAME 2 (y)
29 JUMP_ABSOLUTE 13
32 POP_BLOCK
33 LOAD_CONST 1 (None)
36 RETURN_VALUE
You don't really need the x variable, you just want the square.
It is nothing new that hand-crafted assembler (which mnemonic bytecode
is) can sometimes beat a compiler. In this case, you want store, load,
load before the multiply replaced with dup, and you cannot get that with
Python code without a much smarter optimizer.
--
Terry Jan Reedy
___
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
Re: [Python-Dev] Don't set local variable in a list comprehension or generator
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 my_string? Or am I missing something?
Good question. Anything useful like '-'.join(c for c in 'abc') is the same
as '-'.join('abc'). The same, as far as I can think of, for anything like
list() or set() taking an iterable arg.
With a little imagination you can build something non trivial.
For example, a join_words function:
def join_words(words):
return ', '.join(w.strip() for w in words)
Like Victor says, the code of the generator object contains a
STORE_FAST followed by LOAD_FAST.
This pair of opcodes could be removed, and the value left on the stack.
dis.dis(join_words.func_code.co_consts[2])
1 0 SETUP_LOOP 24 (to 27)
3 LOAD_FAST0 (.0)
6 FOR_ITER17 (to 26)
9 STORE_FAST 1 (w)
12 LOAD_FAST1 (w)
15 LOAD_ATTR0 (strip)
18 CALL_FUNCTION0
21 YIELD_VALUE
22 POP_TOP
23 JUMP_ABSOLUTE6
26 POP_BLOCK
27 LOAD_CONST 0 (None)
30 RETURN_VALUE
As I pointed out in response to Victor, you get nearly the same with
bytecode with regular old for loops; in particular, the store x/load x pair.
It's probably not easy to do though.
Think of expressions where the variable appears several times,
or even where the variable is not the first object, like str(ord(x)).
Where first means first in left-to-right order rather than in innermost
to outermost order. (OT: I think Python is a bit unusual in this way.)
--
Terry Jan Reedy
___
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
Re: [Python-Dev] Inconsistent case in directory names for installed Python on Windows
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 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 programming in general). In theory there are probably a lot of things that might seem unpleasant but are actually non-issues. I don't believe there have been any complaints about actual unpleasantries with directory case. Among web folks there are no people who care less about typography than those who spend most of their time in text terminals. =) I think that probability of receiving such complaint is very low even if everybody notices that. Why should I bother about consistency if Python developers are not giving damn about it? ├[Python27] │ ├─DLLs │ ├─Doc │ ├─include │ ├─Lib │ ├─libs │ ├─Scripts │ ├─tcl │ └─Tools How about making a consistent lowercased or uppercased scheme? Windows filesystems are case-insensitive, so the change shouldn't affect anybody. Some Macs have case-sensitive file systems, and some people use case-sensitive file systems on various flavors of UNIX. The change would probably require a thorough look through the build chain. But we are speaking only about Windows. Another candidate for normalization is Tools/Scripts dir, which I'd lowercase FWIW: └─Tools ├─i18n ├─pynche ├─Scripts ├─versioncheck └─webchecker Lowercased dirs on a top level seem to contains files that are relevant to C developers only. However, I can not say for sure. It seems that there could be a better place for them like top level directory named Dev or C-API. Overall I think it boils down to a cosmetic change that I'm not sure we need to make, which could unnecessarily break people's work. -1 That's right - I started that without cosmetic changes the project becomes ugly and start to accumulate a lot of garbage. With due attention to improving an image of Python from perspective of project layout organization, this change could be made in Python 3. It is something to keep in mind for the future. -- anatoly t. ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 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 sound as if there was a mistake. To clarify: once the final is done, the repo Martin mentioned will be merged back to main and then vanish. 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/ ? -- anatoly t. ___ 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
Re: [Python-Dev] Inconsistent case in directory names for installed Python on Windows
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 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 programming in general). In theory there are probably a lot of things that might seem unpleasant but are actually non-issues. I don't believe there have been any complaints about actual unpleasantries with directory case. Among web folks there are no people who care less about typography than those who spend most of their time in text terminals. =) I think that probability of receiving such complaint is very low even if everybody notices that. Why should I bother about consistency if Python developers are not giving damn about it? ├[Python27] │ ├─DLLs │ ├─Doc │ ├─include │ ├─Lib │ ├─libs │ ├─Scripts │ ├─tcl │ └─Tools How about making a consistent lowercased or uppercased scheme? Windows filesystems are case-insensitive, so the change shouldn't affect anybody. Some Macs have case-sensitive file systems, and some people use case-sensitive file systems on various flavors of UNIX. The change would probably require a thorough look through the build chain. But we are speaking only about Windows. Definitely -1 to change the folder names only on Windows. ___ 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
Re: [Python-Dev] Inconsistent case in directory names for installed Python on Windows
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 want it any way. Since I suspect change on *nix is out, I would feel the same for winX. I actually like having 'Lib' uppercase versus 'libs' lowercase, to make it easier to pick out 'Lib'. Most users have little reason to look as this directory list very often. Certainly, Doc, Lib, Scripts, and Tools are ones they might want to look in, which include, libs, and tcl have nothing to look at. Notice the pattern? Hmmm. By the same logic, DLLs should have been dlls, but I suspect someone wanted to distinguish the plural s from dll. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 main and then vanish. Can't this work be done in the branch of main repo, so that everybody can track the progress in place? As I understand it, this is a snapshot that George hopes will require No work between the candidate and final release and which will get only the minimum needed. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 what track in place means). If you are asking for a named branch: no, that shouldn't be done. Regards, Martin ___ 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
Re: [Python-Dev] Python 3.x and bytes
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? It might seem convenient, but I'd worry that it would lead to even more confusion in other ways. If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is also true, they might expect to be able to do things like n = b'd' + 1 and get 101... or maybe b'e'... Maybe they should :) Georg ___ 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
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
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 3.2.1rc1 will also be merged back soon, since there will be a 3.2.1rc2.) Georg ___ 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
