Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
2009/11/4 Glyph Lefkowitz gl...@twistedmatrix.com: On Nov 3, 2009, at 5:16 PM, Paul Moore wrote: 2009/11/3 Brett Cannon br...@python.org: I'm afraid there is some FUD going around here, which is understandable since no one wants to burn a ton of time on something that will be difficult or take a lot of time. But I have not heard anyone in this email thread (or anywhere for that matter) say that they tried a port in earnest and it turned out to be difficult. FWIW, I did a quick survey of some packages (a sampling of packages I've used or considered using in the past): Twisted - no plans yet for Python 3 Speaking of FUD, we've had a plan for Python 3 support for some time: [...] Thanks, and my sincere apologies for spreading FUD - I did try to find details, and in fact I did spot a couple of the specific python 3 compatibility tickets you mentioned, but missed the link back to the master plan. Having said that, http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3/214601#214601 seems pretty negative in terms of when Twisted will support Python 3. Based on my reading, the focus is more on when 2.x support will be dropped than on when there will be a version of Twisted which works with Python 3 (which I'd expect to be much sooner!) If you're interested in helping, our core team has all not had much time for Twisted lately and we need volunteers who are interested in doing code reviews and becoming a committer to help shepherd these tickets through the process. Personally, I don't *use* twisted. I occasionally play with it, and I sometimes end up using applications which rely on it, but I don't use it myself. So I couldn't be much direct help. (And yes, I know that means I'm not one of your users, so me asking for Python 3 support isn't an issue. No problem there). Paul. ___ 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] PEP 3003 - Python Language Moratorium
On Nov 3, 2009, at 3:42 PM, Michael Foord wrote: Barry Warsaw wrote: On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote: I've checked draft (!) PEP 3003, Python Language Moratorium, into SVN. As authors I've listed Jesse, Brett and myself. On python-ideas the moratorium idea got fairly positive responses (more positive than I'd expected, in fact) but I'm bracing myself for fierce discussion here on python-dev. It's important to me that if if this is accepted it is a rough consensus decision (working code we already have plenty of :-), not something enforced by a vocal minority or an influential individual such as myself. If there's too much opposition I'll withdraw the PEP so as not to waste everybody's time with a fruitless discussion. The PEP tries to spell out some gray areas but I'm sure there will be others; that's life. Do note that the PEP proposes to be *retroactive* back to the 3.1 release, i.e. the frozen version of the language is the state in which it was released as 3.1. I think this is a great idea. I'd love to see the energy normally put into evolving the language into making the stdlib really kick ass. +lots Ditto. Doug ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Wed, 4 Nov 2009 10:10:30 am Guido van Rossum wrote: On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano st...@pearwood.info wrote: Since I was the person who decided that arbitrary meant give a different result each time, I should answer that. You're obviously talking about a *random* element. This is a separate use case (though I agree many people don't know the difference). I'm aware of the difference between random and arbitrary, and in an earlier post I said that the One Obvious Way of getting a random element from a list would be to convert to a list and call random.choice(). Sorry for muddying the waters by linking to a page discussing such random selections. -- Steven D'Aprano ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Wed, 4 Nov 2009 11:54:47 am Greg Ewing wrote: Steven D'Aprano wrote: I don't know how expensive it is to create a set iterator, Not expensive enough to justify burdening the set type with extra functionality that will be extremely rarely used. As my previous posts on this topic tried to convey, this isn't primarily about efficiency, but about discoverability and obviousness. Anyway, given the level of opposition to the suggestion, I'm no longer willing to carry the flag for it. If anyone else -- perhaps the OP -- feels they want to take it any further, be my guest. -- Steven D'Aprano ___ 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] PEP 3003 - Python Language Moratorium
Jack Diederich wrote: +1. There are no compelling language changes on the horizon (yield from is nice but not necessary). Another +1 here. A note in the PEP that there are no changes to SVN that would need to be rolled back due to the moratorium would be a good addition (as per Antoine's review of the NEWS file). 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] Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)
Lennart Regebro wrote: I also would really like to see a real port of the bytes class to 2.6, but I have a vague memory that there was some reason that wouldn't work. Not so much that it wouldn't work, but that the interfaces to support using it effectively really aren't there - lots of areas in the standard library needed to be tweaked to cope with bytes objects in 3.x. Generally speaking, the bytes = str trick represents a reasonable compromise as the APIs that you would pass a bytes object to in 3.x expect an 8-bit str instance in 2.x. 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] A wordcode-based Python
On Tue, May 12, 2009 at 8:54 AM, Cesare Di Mauro cesare.dima...@a-tono.com wrote: Also, I checked out wpython at head to run Unladen Swallow's benchmarks against it, but it refuses to compile with either gcc 4.0.1 or 4.3.1 on Linux (fails in Python/ast.c). I can send you the build failures off-list, if you're interested. Thanks, Collin Winter I'm very interested, thanks. That's because I worked only on Windows machines, so I definitely need to test and fix it to let it run on any other platform. Cesare Re-animating an old discussion -- Cesare, any news on the wpython front? I did a checkout from http://wpython.googlecode.com/svn/trunk and was able to ./configure and make successfully on my 64-bit Linux box as well as to run the Unladen benchmarks. Given svn co http://svn.python.org/projects/python/tags/r261 in py261 and svn co http://wpython.googlecode.com/svn/trunk in wpy, $ python unladen-tests/perf.py -rm --benchmarks=-2to3,all py261/python wpy/python gives the following results: Report on Linux foo 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 Total CPU cores: 2 ai: Min: 0.640516 - 0.586532: 9.20% faster Avg: 0.677346 - 0.632785: 7.04% faster Significant (t=4.336740, a=0.95) Stddev: 0.05839 - 0.08455: 30.94% larger Mem max: 7412.000 - 6768.000: 9.52% smaller Usage over time: http://tinyurl.com/ykwhmcc call_simple: Min: 1.880816 - 1.701622: 10.53% faster Avg: 1.944320 - 1.778701: 9.31% faster Significant (t=14.323045, a=0.95) Stddev: 0.09885 - 0.06000: 64.74% smaller Mem max: 8100.000 - 6636.000: 22.06% smaller Usage over time: http://tinyurl.com/yzsswgp django: Min: 1.287158 - 1.315700: 2.17% slower Avg: 1.330423 - 1.366978: 2.67% slower Significant (t=-4.475769, a=0.95) Stddev: 0.05663 - 0.05885: 3.78% larger Mem max: 15508.000 - 16228.000: 4.44% larger Usage over time: http://tinyurl.com/yfpbmjn iterative_count: Min: 0.211620 - 0.124646: 69.78% faster Avg: 0.222778 - 0.159868: 39.35% faster Significant (t=9.291635, a=0.95) Stddev: 0.04239 - 0.05279: 19.69% larger Mem max: 7388.000 - 6680.000: 10.60% smaller Usage over time: http://tinyurl.com/yj7s8h4 normal_startup: Min: 1.060017 - 0.991366: 6.92% faster Avg: 1.189612 - 1.170067: 1.67% faster Significant (t=2.002086, a=0.95) Stddev: 0.06942 - 0.06864: 1.13% smaller Mem max: 3252.000 - 4648.000: 30.03% larger Usage over time: http://tinyurl.com/ygo3bwt pickle: Min: 2.027566 - 1.948784: 4.04% faster Avg: 2.051633 - 2.043656: 0.39% faster Not significant Stddev: 0.03095 - 0.07348: 57.88% larger Mem max: 8544.000 - 7340.000: 16.40% smaller Usage over time: http://tinyurl.com/ykg9dn2 pickle_dict: Min: 1.658693 - 1.656844: 0.11% faster Avg: 1.689483 - 1.698176: 0.51% slower Not significant Stddev: 0.16945 - 0.09403: 80.20% smaller Mem max: 6716.000 - 7636.000: 12.05% larger Usage over time: http://tinyurl.com/yjhyame pickle_list: Min: 0.919083 - 0.894758: 2.72% faster Avg: 0.956513 - 0.921314: 3.82% faster Significant (t=2.131237, a=0.95) Stddev: 0.12744 - 0.10506: 21.31% smaller Mem max: 6804.000 - 8792.000: 22.61% larger Usage over time: http://tinyurl.com/ylc3ezf pybench: Min: 58781 - 50836: 15.63% faster Avg: 60009 - 51788: 15.87% faster regex_compile: Min: 0.934131 - 0.862323: 8.33% faster Avg: 0.962159 - 0.884848: 8.74% faster Significant (t=13.587168, a=0.95) Stddev: 0.04685 - 0.03229: 45.11% smaller Mem max: 12584.000 - 12740.000: 1.22% larger Usage over time: http://tinyurl.com/yjngu8j regex_effbot: Min: 0.130686 - 0.122483: 6.70% faster Avg: 0.143453 - 0.138078: 3.89% faster Not significant Stddev: 0.01864 - 0.03177: 41.32% larger Mem max: 7652.000 - 6660.000: 14.89% smaller Usage over time: http://tinyurl.com/ykcgntf regex_v8: Min: 0.135130 - 0.150092: 9.97% slower Avg: 0.138027 - 0.177309: 22.15% slower Significant (t=-8.197595, a=0.95) Stddev: 0.00258 - 0.04785: 94.60% larger Mem max: 11124.000 - 12236.000: 9.09% larger Usage over time: http://tinyurl.com/ykb5vzu rietveld: Min: 0.848245 - 0.816473: 3.89% faster Avg: 1.033925 - 1.019889: 1.38% faster Not significant Stddev: 0.11242 - 0.13006: 13.56% larger Mem max: 23792.000 - 24548.000: 3.08% larger Usage over time: http://tinyurl.com/yhdvz5v slowpickle: Min: 0.876736 - 0.800203: 9.56% faster Avg: 0.932808 - 0.870577: 7.15% faster Significant (t=5.020426, a=0.95) Stddev: 0.05600 - 0.11059: 49.36% larger Mem max: 7200.000 - 7276.000: 1.04% larger Usage over time: http://tinyurl.com/ykt2brq slowspitfire: Min: 1.029100 - 0.948458: 8.50% faster Avg: 1.062486 - 1.020777: 4.09% faster Significant (t=4.581669, a=0.95) Stddev: 0.05441 - 0.07298: 25.44% larger Mem max: 139792.000 - 129264.000: 8.14% smaller Usage over time: http://tinyurl.com/yh7vmlh slowunpickle: Min: 0.411744 - 0.356784: 15.40% faster Avg: 0.444638 - 0.393261: 13.06% faster Significant (t=7.009269, a=0.95) Stddev: 0.04147 - 0.06044: 31.38% larger Mem max: 7132.000 - 7848.000: 9.12% larger Usage over time: http://tinyurl.com/yfwvz3g
Re: [Python-Dev] Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)
Nick Coghlan wrote: Lennart Regebro wrote: I also would really like to see a real port of the bytes class to 2.6, but I have a vague memory that there was some reason that wouldn't work. Not so much that it wouldn't work, but that the interfaces to support using it effectively really aren't there - lots of areas in the standard library needed to be tweaked to cope with bytes objects in 3.x. Generally speaking, the bytes = str trick represents a reasonable compromise as the APIs that you would pass a bytes object to in 3.x expect an 8-bit str instance in 2.x. Could you please add such hints, tricks and tips to the wiki page: http://wiki.python.org/moin/PortingToPy3k Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Refactoring installation schemes
On Wed, Oct 28, 2009 at 7:05 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: Ok then I'll work on a patch for that change and start an issue about it soon. As I expected, being able to provide all those paths pulls a lot of other stuffs out of distutils. In fact, almost all the APIs that are located in distutils/sysconfig can be taken out of distutils, and cleaned up for stdlib's benefit. I've started to refactor the code in a module I have called sysconfig, reusing distutils/sysconfig, distutils/command/install and site code. This sysconfig module should provide at the end very useful APIs to query the current Python environment. That's a work in progress but: I've started a branch at /python/branches/tarek_sysconfig so it's easier to get some feedbacks if anyone want to help on this. Regards Tarek ___ 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] 2to3 interactive mode
Glyph Lefkowitz glyph at twistedmatrix.com writes: Keep in mind also that the 2.x translation process is extremely slow and results in a clunky development process. There's no '2to3 -- interactive' commandline that lets me type python 2 at a prompt and get python 3 results out so that I can try experiments on the 3.x interpreter; I have to actually put my experiments into my unit tests and wait 10 minutes to see if it works. It's like writing C++. Please enter a feature request into the bug tracker. Regards Antoine. ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
Terry Reedy wrote: Guido van Rossum wrote: On Tue, Nov 3, 2009 at 9:37 AM, Martin v. Löwis mar...@v.loewis.de wrote: (and no, adding things like nonlocal to 2.7 doesn't making porting of a real application or library any easier, since the existing application or library simply doesn't use that keyword. Agreed. In fact, no change to 2.x can reasonably simplify porting - only changes to 3.x might - except for changes to 2to3, which can simplify porting a lot. But 2to3 should be run under 3.x, IMO.) Disagreed. Better -3 warnings could make porting easier. (Not just more warnings -- better might mean fewer false positives for warnings already issued.) There is also Eric Smith's list to consider: PEP3118 new buffer protocol, short float repr, and maybe io. The pure Python io module was already backported for the 2.6 release [1], as was the C API aspect of PEP 3118 [2]. Short float repr has since been backported for 2.7, as has the C accelerated io module implementation and the Python API (memoryview) aspect of PEP 3118. I believe those 3 features alone are more than enough justification to proceed with at least a 2.7 release (that is probably the point Eric was making in posting that list of features in the first place). As to how those backports can help with forward ports to Py3k, someone made the point elsewhere in the thread that testing/experimenting via 2to3 is a very C++ like development cycle - there is a long build time before you get to see the results of running a test. With features backported to 2.x, you can instead use more traditional version checks (or the interactive prompt) and get the usual quick feedback cycle via the 2.7 version, before submitting your code to the tender mercies of the 2to3 converter (or possibly avoid 2to3 altogether if the version checks turn out to suffice for a given use case). Cheers, Nick. [1] http://docs.python.org/whatsnew/2.6.html#pep-3116-new-i-o-library [2] http://docs.python.org/whatsnew/2.6.html#pep-3118-revised-buffer-protocol -- 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] 2.7 Release? 2.7 == last of the 2.x line?
Hi, I wanted to make some brief comments on this thread: - 2to3 encourages people to see Python 3 as exotic and other---and not to actually write in it. - 3to2 encourages people to use Python 3 and also provides a route to Python 2 compatibility. I hope that a point will be reached where people are encouraged to do a one off 2to3, hand fix, and once it passes their tests to keep a single Python 3 source and use 3to2 to support their users of older Pythons. - Unicode strings is the solution, not the problem, and is one of Python 3's most important advances. - Have any big ports been done? Yes, PyQt4. PyQt4 supports both Python 2 and Python 3---and the port was done by one person in his spare time over a period of months. PyQt4 wraps at least 700,000 lines of C++ code---and it isn't just GUI stuff, it has networking, threading, etc., and works on Linux, Mac, Windows, etc. - I do hope NumPy gets ported, since both on and off the lists it seems like a show-stopper for many people. - I hope the ditch 3 calls are ignored. Python 3 is significantly better than (an already excellent) Python 2: eventually people will port---or those who start out with Python 3 will build their own libraries for what's missing, just as people did when Python 2 came out. - I think the developers have done a fantastic job with Python 3. I just wish more people realised how good it is! Regarding the Moratorium: +inf since I'd really love to see more time devoted to improving the standard library. My 2c:-) -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy Advanced Qt Programming - ISBN 0321635906 ___ 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] Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)
M.-A. Lemburg wrote: Nick Coghlan wrote: Lennart Regebro wrote: I also would really like to see a real port of the bytes class to 2.6, but I have a vague memory that there was some reason that wouldn't work. Not so much that it wouldn't work, but that the interfaces to support using it effectively really aren't there - lots of areas in the standard library needed to be tweaked to cope with bytes objects in 3.x. Generally speaking, the bytes = str trick represents a reasonable compromise as the APIs that you would pass a bytes object to in 3.x expect an 8-bit str instance in 2.x. Could you please add such hints, tricks and tips to the wiki page: http://wiki.python.org/moin/PortingToPy3k Done (although the task of figuring out how to get the wiki to display code properly defeated me... the normal Python documentation syntax for it seemed to give the wiki's ReST interpreter fits). I also mentioned the trick someone mentioned about from __future__ import unicode_literals not changing the meaning of 'str' since it only alters the parser but not the builtins. In writing it up, it occurred to me that having that kind of thing in a py3_compat compatibility module (to be used as, e.g., from py3_compat import str, bytes) would not only make it easier to use in multiple modules, but also easier for 2to3 to remove when forward porting. 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] A wordcode-based Python
Hi Mart I had some problems and little time to dedicate to wpython in the last period, but I restarted again with it in the last month. Currently I'm working on changing and documenting the code so that almost every optimization can be selected. So you'll compile it enabling only the ones you are interested in. I've also investigated about some ideas which Antoine told me on grouping together FASTs and CONSTs in order to reduce bytecodes, but I've found that the suggested solution brings some problems with the current function call implementation that can hurt performance on some situations (mostly with recursive ones, because usually they need to create new frames, and constants references must be copied and INCREFed). Since it will require huge changes to the current code base, I don't know if it's worth the effort just to verify the idea. I'll think about it when the project will be finalized. My plan is to finish the current work in a few days, and then remove the (may be ugly) hacks that I made to the Python object model that were needed to let tuples, lists and dictionaries be loaded as CONSTs. May be a the end of the month it'll be fixed (and the diffs against CPython will be reduced a lot, since a few files results changed). Next, I need to changed the trace code (in frameobject.c) to let the test_trace.py pass (at this time two tests are disabled because the VM crashes). Finally, I think to update the code base to 2.6.4. I think to release everything at the end of the year, but if someone is interested I can do a partial release at the end of November. Regarding your tests, they are very interesting, particularly for regex_v8 that showed an unexpected result for me. I'll investigate about it after I'll release wpython. I you have any questions, I'm at your disposal (thanks for your tests!) Cesare 2009/11/4 Mart Sõmermaa mrts.py...@gmail.com On Tue, May 12, 2009 at 8:54 AM, Cesare Di Mauro cesare.dima...@a-tono.com wrote: Also, I checked out wpython at head to run Unladen Swallow's benchmarks against it, but it refuses to compile with either gcc 4.0.1 or 4.3.1 on Linux (fails in Python/ast.c). I can send you the build failures off-list, if you're interested. Thanks, Collin Winter I'm very interested, thanks. That's because I worked only on Windows machines, so I definitely need to test and fix it to let it run on any other platform. Cesare Re-animating an old discussion -- Cesare, any news on the wpython front? I did a checkout from http://wpython.googlecode.com/svn/trunk and was able to ./configure and make successfully on my 64-bit Linux box as well as to run the Unladen benchmarks. Given svn co http://svn.python.org/projects/python/tags/r261 in py261 and svn co http://wpython.googlecode.com/svn/trunk in wpy, $ python unladen-tests/perf.py -rm --benchmarks=-2to3,all py261/python wpy/python gives the following results: Report on Linux foo 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 Total CPU cores: 2 ai: Min: 0.640516 - 0.586532: 9.20% faster Avg: 0.677346 - 0.632785: 7.04% faster Significant (t=4.336740, a=0.95) Stddev: 0.05839 - 0.08455: 30.94% larger Mem max: 7412.000 - 6768.000: 9.52% smaller Usage over time: http://tinyurl.com/ykwhmcc call_simple: Min: 1.880816 - 1.701622: 10.53% faster Avg: 1.944320 - 1.778701: 9.31% faster Significant (t=14.323045, a=0.95) Stddev: 0.09885 - 0.06000: 64.74% smaller Mem max: 8100.000 - 6636.000: 22.06% smaller Usage over time: http://tinyurl.com/yzsswgp django: Min: 1.287158 - 1.315700: 2.17% slower Avg: 1.330423 - 1.366978: 2.67% slower Significant (t=-4.475769, a=0.95) Stddev: 0.05663 - 0.05885: 3.78% larger Mem max: 15508.000 - 16228.000: 4.44% larger Usage over time: http://tinyurl.com/yfpbmjn iterative_count: Min: 0.211620 - 0.124646: 69.78% faster Avg: 0.222778 - 0.159868: 39.35% faster Significant (t=9.291635, a=0.95) Stddev: 0.04239 - 0.05279: 19.69% larger Mem max: 7388.000 - 6680.000: 10.60% smaller Usage over time: http://tinyurl.com/yj7s8h4 normal_startup: Min: 1.060017 - 0.991366: 6.92% faster Avg: 1.189612 - 1.170067: 1.67% faster Significant (t=2.002086, a=0.95) Stddev: 0.06942 - 0.06864: 1.13% smaller Mem max: 3252.000 - 4648.000: 30.03% larger Usage over time: http://tinyurl.com/ygo3bwt pickle: Min: 2.027566 - 1.948784: 4.04% faster Avg: 2.051633 - 2.043656: 0.39% faster Not significant Stddev: 0.03095 - 0.07348: 57.88% larger Mem max: 8544.000 - 7340.000: 16.40% smaller Usage over time: http://tinyurl.com/ykg9dn2 pickle_dict: Min: 1.658693 - 1.656844: 0.11% faster Avg: 1.689483 - 1.698176: 0.51% slower Not significant Stddev: 0.16945 - 0.09403: 80.20% smaller Mem max: 6716.000 - 7636.000: 12.05% larger Usage over time: http://tinyurl.com/yjhyame pickle_list: Min: 0.919083 - 0.894758: 2.72% faster Avg: 0.956513 - 0.921314: 3.82% faster Significant (t=2.131237, a=0.95) Stddev: 0.12744
Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
On Tue, Nov 3, 2009 at 9:51 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote (amongst way too many words): [...] For example, 2.8 could emit a deprecation warning for every old-style class that was defined, 2.9 could emit a deprecation warning for every string constant declared without a 'b' or 'u' prefix unless the module in question were in 3.x mode (i.e. no-prefix == 'u'). This proposal is hopelessly naive. It has been considered seriously from all possible sides before, and there just isn't a way to make this work. Not even with several releases as stepping points. -- --Guido van Rossum (python.org/~guido) ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
At 12:51 AM 11/4/2009 -0500, Glyph Lefkowitz wrote: With the 2.x series, users and operating systems seem to move on fairly rapidly, because dependencies generally continue to work if you upgrade just one version. This isn't quite as formal a requirement as I would like (warnings get generated, unit tests fail, things do break) but in practice, users can rely on it for most functionality. If 3.x could be broken into a series of transitions like that, where you can upgrade one version, fix some stuff, then upgrade another version, even if you couldn't actually support more than 2 versions at once, I think that we could pick up the migration pace to the point where we might actually be using 3.x syntax in a few years. Having a 2.x series which goes to 2.9 and then stops isn't *quite* the same thing as having one that moves over continuously to some 3.x version, but it does seem to me that by that point the chasm between versions will have narrowed to a crack, and the migration will be a little hop over it rather than the currently-required great flying leap. +1 (I actually thought this was the original plan.) ___ 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] A wordcode-based Python
On Wed, Nov 4, 2009 at 4:20 AM, Mart Sõmermaa mrts.py...@gmail.com wrote: On Tue, May 12, 2009 at 8:54 AM, Cesare Di Mauro cesare.dima...@a-tono.com wrote: Also, I checked out wpython at head to run Unladen Swallow's benchmarks against it, but it refuses to compile with either gcc 4.0.1 or 4.3.1 on Linux (fails in Python/ast.c). I can send you the build failures off-list, if you're interested. Thanks, Collin Winter I'm very interested, thanks. That's because I worked only on Windows machines, so I definitely need to test and fix it to let it run on any other platform. Cesare Re-animating an old discussion -- Cesare, any news on the wpython front? I did a checkout from http://wpython.googlecode.com/svn/trunk and was able to ./configure and make successfully on my 64-bit Linux box as well as to run the Unladen benchmarks. Given svn co http://svn.python.org/projects/python/tags/r261 in py261 and svn co http://wpython.googlecode.com/svn/trunk in wpy, $ python unladen-tests/perf.py -rm --benchmarks=-2to3,all py261/python wpy/python Do note that the --track_memory option to perf.py imposes some overhead that interferes with the performance figures. I'd recommend running the benchmarks again without --track_memory. That extra overhead is almost certainly what's causing some of the variability in the results. Collin Winter ___ 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] A wordcode-based Python
On Wed, Nov 4, 2009 at 5:54 PM, Collin Winter coll...@gmail.com wrote: Do note that the --track_memory option to perf.py imposes some overhead that interferes with the performance figures. Thanks for the notice, without -m/--track_memory the deviation in results is indeed much smaller. I'd recommend running the benchmarks again without --track_memory. Done: $ python unladen-tests/perf.py -r --benchmarks=-2to3,all py261/python wpy/python Report on Linux zeus 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 Total CPU cores: 2 ai: Min: 0.629343 - 0.576259: 9.21% faster Avg: 0.634689 - 0.581551: 9.14% faster Significant (t=39.404870, a=0.95) Stddev: 0.01259 - 0.00484: 160.04% smaller call_simple: Min: 1.796710 - 1.700046: 5.69% faster Avg: 1.801533 - 1.716367: 4.96% faster Significant (t=137.452069, a=0.95) Stddev: 0.00522 - 0.00333: 56.64% smaller django: Min: 1.280840 - 1.275350: 0.43% faster Avg: 1.287179 - 1.287233: 0.00% slower Not significant Stddev: 0.01055 - 0.00581: 81.60% smaller iterative_count: Min: 0.211744 - 0.123271: 71.77% faster Avg: 0.213148 - 0.128596: 65.75% faster Significant (t=88.510311, a=0.95) Stddev: 0.00233 - 0.00926: 74.80% larger normal_startup: Min: 0.520829 - 0.516412: 0.86% faster Avg: 0.559170 - 0.554678: 0.81% faster Not significant Stddev: 0.02031 - 0.02093: 2.98% larger pickle: Min: 1.988127 - 1.926643: 3.19% faster Avg: 2.000676 - 1.936185: 3.33% faster Significant (t=36.712505, a=0.95) Stddev: 0.01650 - 0.00603: 173.67% smaller pickle_dict: Min: 1.681116 - 1.619192: 3.82% faster Avg: 1.701952 - 1.629548: 4.44% faster Significant (t=34.513963, a=0.95) Stddev: 0.01721 - 0.01200: 43.46% smaller pickle_list: Min: 0.918128 - 0.884967: 3.75% faster Avg: 0.925534 - 0.891200: 3.85% faster Significant (t=60.451407, a=0.95) Stddev: 0.00496 - 0.00276: 80.00% smaller pybench: Min: 58692 - 51128: 14.79% faster Avg: 59914 - 52316: 14.52% faster regex_compile: Min: 0.894190 - 0.816447: 9.52% faster Avg: 0.900353 - 0.826003: 9.00% faster Significant (t=24.974080, a=0.95) Stddev: 0.00448 - 0.02943: 84.78% larger regex_effbot: Min: 0.124442 - 0.123750: 0.56% faster Avg: 0.134908 - 0.126137: 6.95% faster Significant (t=5.496357, a=0.95) Stddev: 0.01581 - 0.00218: 625.68% smaller regex_v8: Min: 0.132730 - 0.143494: 7.50% slower Avg: 0.134287 - 0.147387: 8.89% slower Significant (t=-40.654627, a=0.95) Stddev: 0.00108 - 0.00304: 64.34% larger rietveld: Min: 0.754050 - 0.737335: 2.27% faster Avg: 0.770227 - 0.754642: 2.07% faster Significant (t=7.547765, a=0.95) Stddev: 0.01434 - 0.01486: 3.49% larger slowpickle: Min: 0.858494 - 0.795162: 7.96% faster Avg: 0.862350 - 0.799479: 7.86% faster Significant (t=133.690989, a=0.95) Stddev: 0.00394 - 0.00257: 52.92% smaller slowspitfire: Min: 0.955587 - 0.909843: 5.03% faster Avg: 0.965960 - 0.925845: 4.33% faster Significant (t=16.351067, a=0.95) Stddev: 0.01237 - 0.02119: 41.63% larger slowunpickle: Min: 0.409312 - 0.346982: 17.96% faster Avg: 0.412381 - 0.349148: 18.11% faster Significant (t=242.889869, a=0.95) Stddev: 0.00198 - 0.00169: 17.61% smaller startup_nosite: Min: 0.195620 - 0.194328: 0.66% faster Avg: 0.230811 - 0.238523: 3.23% slower Significant (t=-3.869944, a=0.95) Stddev: 0.01932 - 0.02052: 5.87% larger threaded_count: Min: 0.222133 - 0.133764: 66.06% faster Avg: 0.236670 - 0.147750: 60.18% faster Significant (t=57.472693, a=0.95) Stddev: 0.01317 - 0.00813: 61.98% smaller unpack_sequence: Min: 0.000129 - 0.000119: 8.43% faster Avg: 0.000132 - 0.000123: 7.22% faster Significant (t=24.614061, a=0.95) Stddev: 0.3 - 0.00011: 77.02% larger unpickle: Min: 1.191255 - 1.149132: 3.67% faster Avg: 1.218023 - 1.162351: 4.79% faster Significant (t=21.222711, a=0.95) Stddev: 0.02242 - 0.01362: 64.54% smaller unpickle_list: Min: 0.880991 - 0.965611: 8.76% slower Avg: 0.898949 - 0.985231: 8.76% slower Significant (t=-17.387537, a=0.95) Stddev: 0.04838 - 0.01103: 338.79% smaller ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 4, 2009, at 1:06 AM, Lennart Regebro wrote: 2009/11/3 sstein...@gmail.com sstein...@gmail.com: On Nov 2, 2009, at 7:26 PM, James Y Knight wrote: It really sounds like you're saying that switching to 3.x isn't worth the cost to you, but you want to force people (including yourself) to do so anyways, because ...? Because that's the future of Python Or not. Maybe it's a dead branch of Python? Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. S ___ 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] Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)
Nick Coghlan wrote: Lennart Regebro wrote: I also would really like to see a real port of the bytes class to 2.6, but I have a vague memory that there was some reason that wouldn't work. Not so much that it wouldn't work, but that the interfaces to support using it effectively really aren't there - lots of areas in the standard library needed to be tweaked to cope with bytes objects in 3.x. I see the problem differently: if a bytes type was added, nothing would use it. In particular, IO wouldn't start returning bytes (although it could accept them); IO would continue to return str. Therefore, I'm skeptical that adding a *third* string type to 3.x would do any good. 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] 2.7 Release? 2.7 == last of the 2.x line?
On 11/4/09, sstein...@gmail.com sstein...@gmail.com wrote: Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. delurk As a user, I'm horrified. Granted, I'm not the most high powered user, but . . . my employer is already providing me with a 3.0 Python version on one of my work computers with the expectation that I'll be using it more and more. Sorry to butt in, but is this a joke? I thought all this was hashed out prior to inventing python 3.0. /delurk ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
That's not going to happen. Stop trolling the python-dev list. On Wed, Nov 4, 2009 at 1:20 PM, sstein...@gmail.com sstein...@gmail.comwrote: Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Wed, Nov 4, 2009 at 10:39 AM, Carl Trachte ctrac...@gmail.com wrote: On 11/4/09, sstein...@gmail.com sstein...@gmail.com wrote: Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. delurk As a user, I'm horrified. Granted, I'm not the most high powered user, but . . . my employer is already providing me with a 3.0 Python version on one of my work computers with the expectation that I'll be using it more and more. Sorry to butt in, but is this a joke? I thought all this was hashed out prior to inventing python 3.0. /delurk I have no idea who ssteinerX is. He certainly doesn't speak for the core developers. -- --Guido van Rossum (python.org/~guido) ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
Antoine Pitrou wrote: Paul Moore p.f.moore at gmail.com writes: FWIW, I did a quick survey of some packages (a sampling of packages I've used or considered using in the past): Twisted - no plans yet for Python 3 Well Twisted depends on zope.interface which is not ported yet. That's not strictly true, see http://svn.zope.org/zope.interface/branches/regebro-python3/ While this isn't released yet, Lennart and myself have been working to make it work on 2.x and 3.x. So porting activities *could* start now (requiring 3.x user to use that branch). 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] 2.7 Release? 2.7 == last of the 2.x line?
For one thing, we have a very long row to hoe here. The migration to 3.0 is a long, tedious process with little tangible benefit. I hope that sometime in the next decade Twisted can accelerate the process of dropping old 2.x versions, but I seriously doubt we could do a feature-complete 3.1/2.6 version. I get the general impression that a 3.2/2.7 port would be more feasible; hopefully a 3.3/2.8 would be even moreso. Please understand that you will not need to drop 2.x versions in order to support 3.x. Just add 3.x support now and make sure it won't break 2.x support. Also, the benefits of migrating to python 3.x are still negligible, as far as I can tell. For Twisted, most definitely - you will need to support 2.x and 3.x simultaneously, so you can't really benefit from 3.x-only changes for a long time to come - perhaps until a 3to2 tool has a good quality, and probably not even then (since it will restrict you what you can do in 3.x code). On the other hand, you've got NumPy, PyGTK, Unladen Swallow, PyPy, Jython, IronPython, and so on and so forth. Since I started using it, the strength of Python has been in its ecosystem, and the 3.x ecosystem is not yet viable. Right - the advantages wouldn't be for Twisted itself, but for users of Twisted, which would see a larger ecosystem if Twisted was available. The main reason I want a long 2.x series is that I believe it would more easily allow us infrastructure folks to drop support for *older* versions. With this big 2.x-3.x chasm, I can't really see an end in sight for Twisted using Python 2.x as its _source_ language, translating with 2to3. Well, 3to2 would then be an option for you: use Python 3 as the source language. Some projects which depend on Twisted and want new versions (and security fixes, etc) are going to want Python 2.x for a really long time. Maybe they're just really conservative, maybe they don't have a lot of maintenance energy, or maybe they have other dependencies which haven't got a port; it doesn't really matter, empirically speaking people want older versions of Python. But wouldn't these applications also break as Twisted drops support for old 2.x versions, and the applications fail to work on the newer 2.x version (say, 2.34)? Keep in mind also that the 2.x translation process is extremely slow and results in a clunky development process. There's no '2to3 --interactive' commandline that lets me type python 2 at a prompt and get python 3 results out so that I can try experiments on the 3.x interpreter; I have to actually put my experiments into my unit tests and wait 10 minutes to see if it works. It's like writing C++. That's not my experience. I see a change in source (say, on Django) available for 3.x within 5 seconds. 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] No buildbot to test wide unicode?
It seems that there is no buildbot to test a wide unicode build. On http://www.python.org/dev/buildbot/3.x/ all outputs of the configure steps show this message:: checking what type to use for str... unsigned short which looks like a ucs2 build to me. Since wide unicode is the standard chosen by some Linux distributions, it would make sense to have at least one buildbot running with --with-wide-unicode (3.x) or --enable-unicode=ucs4 (2.x). Can you propose some (one? two? more?) systems that might be best as candidates? I'd then setup two (sets of) builders; they would share the slave lock, so builds would run sequentially (unless the slave operator agrees to setup two slaves on one machine). 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 4, 2009, at 1:39 PM, Carl Trachte wrote: On 11/4/09, sstein...@gmail.com sstein...@gmail.com wrote: Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. delurk As a user, I'm horrified. Granted, I'm not the most high powered user, but . . . my employer is already providing me with a 3.0 Python version on one of my work computers with the expectation that I'll be using it more and more. Sorry to butt in, but is this a joke? I thought all this was hashed out prior to inventing python 3.0. Yes, of course it was a joke. 2.7 won't turn into Python 3.x any more that Perl will turn into Ruby. Oh, wait, maybe that was a bad example. The point was, that Python 3.x does not seem to be something that can be evolved into and, all along, I have been suggesting that, if Python 3.x is the future, let's let 2.7 be the last of the 2.x series, backport whatever will make it easiest to make 2to3 do as much of the work as possible, and just decide that 2.7 is the end of the line. I shudder to think how much time has been spent hacking things around to make them compatible with the 2.x series while trying to move to 3.x. If 2.x is over, let it be over and let's all focus on moving into Python 3.x with no more time doing other than bug-fixes on 2.x versions of things. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Thu, Nov 5, 2009 at 4:02 AM, Martin v. Löwis mar...@v.loewis.de wrote: That's not my experience. I see a change in source (say, on Django) available for 3.x within 5 seconds. This is for which version of 2to3 ? I got similar experience (several minutes), but maybe I am using 2to3 the wrong way. On my machine, with 2to3 from 3.1.1, it takes ~ 1s to convert one single file of 200 lines, and converting a tiny subset of numpy takes one minute. 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] 2.7 Release? 2.7 == last of the 2.x line?
On Wed, Nov 4, 2009 at 12:02 PM, Martin v. Löwis mar...@v.loewis.dewrote: The main reason I want a long 2.x series is that I believe it would more easily allow us infrastructure folks to drop support for *older* versions. With this big 2.x-3.x chasm, I can't really see an end in sight for Twisted using Python 2.x as its _source_ language, translating with 2to3. Well, 3to2 would then be an option for you: use Python 3 as the source language. A migration path which would be made all the more compelling with the addition of the nonlocal keyword to 2.7 ;-) Mike ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
That's not my experience. I see a change in source (say, on Django) available for 3.x within 5 seconds. This is for which version of 2to3 ? I got similar experience (several minutes), but maybe I am using 2to3 the wrong way. On my machine, with 2to3 from 3.1.1, it takes ~ 1s to convert one single file of 200 lines, and converting a tiny subset of numpy takes one minute. The version released with 3.1. The trick is not to recompile all 2to3 code every time you make a source change. Instead, cache the 2to3 output in the build area, and have setup.py only invoke 2to3 for the files that got modified. So whenever I make a change, I do python3 setup.py install. This checks all timestamps, finds the modified files (which will only be one), runs 2to3 on it, and then copies it into my 3.1 installation, where I can test the change. Recompiling a single file typically takes a few seconds, or less. It would be possible to also run out of the build area; you still would need to run setup.py build after every change. There is already support for this in both distutils (as released in 3.1), and distribute. 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] PEP 3003 - Python Language Moratorium
On Tue, Nov 3, 2009 at 12:35 PM, Guido van Rossum gu...@python.org wrote: I've checked draft (!) PEP 3003, Python Language Moratorium, into SVN. As authors I've listed Jesse, Brett and myself. +1 from me. -- Alexandre ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Wed, Nov 4, 2009 at 6:34 AM, Steven D'Aprano st...@pearwood.info wrote: On Wed, 4 Nov 2009 11:54:47 am Greg Ewing wrote: Steven D'Aprano wrote: I don't know how expensive it is to create a set iterator, Not expensive enough to justify burdening the set type with extra functionality that will be extremely rarely used. As my previous posts on this topic tried to convey, this isn't primarily about efficiency, but about discoverability and obviousness. Anyway, given the level of opposition to the suggestion, I'm no longer willing to carry the flag for it. If anyone else -- perhaps the OP -- feels they want to take it any further, be my guest. -- Steven D'Aprano I've said before that I'd like there to be one, standard way of doing this. A function call- set.pick() seems reasonably named to me- is probably the cleanest way to do that. Absent that, an example in the docs that illustrates the preferred idiom would be great. Is there any kind of consensus on either point? Geremy Condra ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Wed, Nov 4, 2009 at 10:20, sstein...@gmail.com sstein...@gmail.com wrote: On Nov 4, 2009, at 1:06 AM, Lennart Regebro wrote: 2009/11/3 sstein...@gmail.com sstein...@gmail.com: On Nov 2, 2009, at 7:26 PM, James Y Knight wrote: It really sounds like you're saying that switching to 3.x isn't worth the cost to you, but you want to force people (including yourself) to do so anyways, because ...? Because that's the future of Python Or not. Maybe it's a dead branch of Python? Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. I am going to say this once: we are not killing off Python 3. First off, Python 3 is not even a year old! Considering people have not fully migrated to 2.6, should we kill it off as well? There is a certain lack of perspective on time scale. This is especially true when Guido himself has said on multiple occasions that moving the community to 3.x would be a mult-year process, as in 3-5 years process, not 11 months. Second, the people calling for us to potentially kill 3.x and just keep 2.x floating along have yet to say that they have tried porting their code and that it was difficult. Every person who has stepped forward stating they have done a port has said it was actually relatively straight-forward. Not only that, we have anecdotal evidence from multiple people that you can support code way back to whatever old version of Python RHEL is running. Third, the same people calling for the death of 3.x have not suggested they have used it extensively (if at all). I have yet to hear anyone say that 3.x is not at least a nice improvement, if not a huge one. I for one find 3.x more enjoyable to work in than 2.x, and that's saying a lot since I obviously loved Python 2.x enough to get involved in its development. I have also never heard anyone ever say, I gave 3.x a fair shake and honestly, I wish I had not wasted the time. Wait until 3to2 gets to a good state (which will happen; it's my next project -- after I either get us moved to Hg or I simply give up on it -- and I know I am not the only core developer planning on making it happen). I realize that there is some fear that it will be time wasted if people port their code to 3.x if it somehow burns out. But do you honestly think that python-dev would leave you hanging like that? Let's take a worst-case scenario here and say that direct pick-up of 3.x after a couple years never happens. Fine, we then begin to backport features. But if you already ported your code then chances are you already support the new features. And you know what one of the first things we would back port would be? Unicode strings and bytes. And since that is the hardest thing to port to, you will have not wasted any time. In other words the calling for the death of 3.x is rather premature and honestly unfair until people have actually tried to port their code in earnest and it has been a couple of years for the community to catch up to what python-dev is pushing out the door (which always takes a while no matter what minor version has been released). -Brett ___ 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] Refactoring installation schemes
On Wed, 4 Nov 2009 13:29:35 +0100, Tarek Ziadé ziade.ta...@gmail.com wrote: I've started to refactor the code in a module I have called sysconfig, reusing distutils/sysconfig, distutils/command/install and site code. This sysconfig module should provide at the end very useful APIs to query the current Python environment. That's a work in progress but: I've started a branch at /python/branches/tarek_sysconfig so it's easier to get some feedbacks if anyone want to help on this. Good job so far. Keep going. imho a refactoring of the installation and build schemes of distutils is due. It seems like you easily have the skills to do it. My advice would be to do it gradually, as you are. And focus on simplification, and filling in the functional gaps. Ask people what the functional gaps are on their platforms and try to mould it together in an unplatform specific way. Myself and others can assist with this, but best to do it on distutils-sig. I would even go so far as to use the python 3 as a carrot for the new work. imho The biggest and best thing that you could do for python packaging is to do a refactor of the .EGG format. What I mean here, is *take* the egg, and run with it. Modernise it and revamp it into a platform independent thing. People 'get' the egg idea, they just hate the current implementation. What we all *need* is for the egg to be what the source distribution now is. Not for it to be some proprietory out out of python object. Call it the new Tarek egg... Then refactor distutils build to focus on good egg creation.. Many people will help you.. including myself.. 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
[Python-Dev] 2to3, 3to2: official status (was: 2.7 Release? 2.7 == last of the 2.x line?)
Martin v. Löwis mar...@v.loewis.de writes: Well, 3to2 would then be an option for you: use Python 3 as the source language. I was under the impression that 2to3 was officially supported as part of Python, but 3to2 was a third-party tool. What's the status of 3to2 now? Is it an official part of Python? -- \ “A free society is one where it is safe to be unpopular.” | `\—Adlai Ewing Stevenson | _o__) | Ben Finney ___ 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] 2to3, 3to2: official status (was: 2.7 Release? 2.7 == last of the 2.x line?)
On Wed, Nov 4, 2009 at 14:23, Ben Finney ben+pyt...@benfinney.id.au wrote: Martin v. Löwis mar...@v.loewis.de writes: Well, 3to2 would then be an option for you: use Python 3 as the source language. I was under the impression that 2to3 was officially supported as part of Python, but 3to2 was a third-party tool. What's the status of 3to2 now? Is it an official part of Python? Nope, third-party while it continues to mature. -Brett ___ 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] Refactoring installation schemes
On Wed, Nov 4, 2009 at 5:16 PM, David Lyon david.l...@preisshare.net wrote: I would even go so far as to use the python 3 as a carrot for the new work. The packaging story is in such bad shape that it needs the work regardless, and keeping it to Python 3 would significantly reduce the set of potential volunteers. imho The biggest and best thing that you could do for python packaging is to do a refactor of the .EGG format. What I mean here, is *take* the egg, and run with it. Modernise it and revamp it into a platform independent thing. People 'get' the egg idea, they just hate the current implementation. There's certainly work on that, but... is it that people hate the format? Or working with setuptools? The fact that there's more than one egg format doesn't help, so you may be right. Call it the new Tarek egg... The tegg? ;-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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] 2to3, 3to2: official status
Ben Finney wrote: Martin v. Löwis mar...@v.loewis.de writes: Well, 3to2 would then be an option for you: use Python 3 as the source language. I was under the impression that 2to3 was officially supported as part of Python, but 3to2 was a third-party tool. What's the status of 3to2 now? Is it an official part of Python? No, the status is exactly as you describe 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] 2.7 Release? 2.7 == last of the 2.x line?
Folks: It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the new unicode regime. I think the answer is that the payoff is just *so* low to me at this point that it doesn't even justify me taking 15 minutes to read What's New In Python 3 or to execute 2to3 on my smallest package and see what it does. On the other hand, I'm totally committed to supporting Python 2.7, because my customers will demand it and because I expect that it will be easy. So, if you guys slip in your favorite new Python 3 feature into 2.7 and add a deprecation warning for your least favorite Python 2 misfeature, then probably within about 24 months I'll have fixed all code that uses the deprecated feature, and probably within about five years I'll consider dropping backwards-compatibility with Python 2.6 and starting to use that new feature that you added to Python 2.7. (I'm currently considering dropping Python 2.4 compatibility for the next releases of most of my code.) Regards, Zooko ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
2009/11/4 Zooko O'Whielacronx zoo...@gmail.com: On the other hand, I'm totally committed to supporting Python 2.7, because my customers will demand it and because I expect that it will be easy. Why do you think your customers will demand 2.7 support but not 3.1 support? If I were one of your customers, I'd want 3.1 support... Paul. ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Wed, Nov 04, 2009 at 03:54:44PM -0700, Zooko O'Whielacronx wrote: It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the new unicode regime. I think the answer is that the payoff is just *so* low to me at this point that it doesn't even justify me taking 15 minutes to read What's New In Python 3 or to execute 2to3 on my smallest package and see what it does. cynical mode You have time to read this thread but no time to read What's New In Python 3? /cynical mode Personally I found porting to Python 3 a rather pleasant experience (include C extension module). I can't wait until I can drop support for Python 2.2-2.X. Regards Floris PS: I have to admit that the commerial code base I work on is still at Python 2.5, but that doesn't make me worry in any way. It'll get to Python 3 in time (it's running on 2.6 already in development). -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ 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] PyCon 2010: Poster sessions
PyCon 2010: Poster sessions === Due date: November 30, 2009 PyCon 2010 introduces a new type of presentation, the poster session. Poster sessions consist of two pieces: * A display space where you can put up information about a topic * Live QA during a plenary timeslot where people can get more information from you while you stand next to your display For more information and to submit a poster proposal, visit http://us.pycon.org/2010/conference/posters/ -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ [on old computer technologies and programmers] Fancy tail fins on a brand new '59 Cadillac didn't mean throwing out a whole generation of mechanics who started with model As. --Andrew Dalke ___ 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] Refactoring installation schemes
On Wed, 4 Nov 2009 17:40:35 -0500, Fred Drake fdr...@acm.org wrote: The packaging story is in such bad shape that it needs the work regardless, and keeping it to Python 3 would significantly reduce the set of potential volunteers. Well I guess that is a 'marketing decision'. Not a coding issue. Actually, I don't honestly think that there is a lack of volounteers or any lack of resources. The main challenge imho is to get peoples bikesheds (including my own bikeshed) to line up in such a way that people can ride together sharing some sort of parts. Tarek has been doing just fine at facilitating this. There's certainly work on that, but... is it that people hate the format? Or working with setuptools? In my experience, working with the setuptools implementation is the difficult part. There's a barrage of impossible to remember command line options and the documentation is imho more convoluted than it needs to be. Let me put the distutils documentation forward as some sort of reference as to where the setuptools documentation should be. Then, there are some relatively minor issues that just annoy users to no end. The simple one is that they live in your site-packages directory unpacked. People wouldn't have so many issues if they lived like every other 'normal' package. As for the format itself, there's nothing to hate that I can see. The fact that there's more than one egg format doesn't help, so you may be right. Yes. The implementation can be confusing. That's the only problem imo. Call it the new Tarek egg... The tegg? ;-) l'oeuf ? In summmary, it doesn't matter so much what an 'egg' is. All that is important is that it works on lots of python platforms, distutils can easily pop them out, they are well documented and relatively trouble free. Most importantly, credit for the original idea goes back to PJE and everything gets refactored to make it 'nice'. I don't think it's a massive refactoring operation myself, and I'm very sure well within Tareks skillset to take on. 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] 2.7 Release? 2.7 == last of the 2.x line?
Glyph Lefkowitz wrote: For what it's worth, the official position of the Twisted project is not that we have no plan to move to Python 3. It's that our plan is to do exactly as Raymond suggests, and give the users a vote - in this case, you vote with your patches :). You probably will not hear from potential users who skip Twisted because it is not available for 3.x. I suspect you do not hear much either from new users who only installed 2.x to use Twisted, but would prefer 3.x. There are regular questions on python-list about 'web programming with 3.0' or some such. For one thing, we have a very long row to hoe here. The migration to 3.0 is a long, tedious process with little tangible benefit. One group that benefits is new Python programmers. Python 3 is easier to learn, and is being used to teach Python in at least some schools and universities, and will be used more as more libraries are available. Hardly a week goes by on Python list without someone posting a problem using 2.x that has been solved in 3.x. Another group is existing programmers who were/are sufficiently annoyed by some of the things that got cleaned up. A third group is people who want to use non-ascii in identifiers, and who are delighted now that they can. Since you do not fall in these groups, I understand your impatience and reluctance with the change. I can also imagine that Twisted may be more affected by some of the changes than most other projects. [snip more] ... There have been some other comments in this thread indicating that this was not the case because some users indicated that they'd rather deal with lots of changes all at once. I wrote that based on both my reading of clp/pylist posts during the discussion of the int/int semantic change and Guido's report of private conversations he had had. My understanding is that it was done this way so that the *developers* of Python could make a clean break, and design and implement a new version of Python without being constrained by compatibility concerns. I do not believe that was ever intended. It certainly is not what happened; many changes were not made *because* of compatibility concerns and all went through the filter of 'is the benefit of this change worth the pain of breakage'. There is a big difference between not being straightjacketed and being unconstrained. If you can show me an actual application or library developer in Python who wanted this one-big-jump migration, I will show you a crazy person. Be careful of labels. Once the prolonged and intense int/int debate shifted from the ontology of ints to the pragmatics of the proposed change, most people agreed that int/int 'should' have meant float(int)/float(int) from the beginning. But some were still strongly opposed to making the change because they (understandably) did not want to have to scan (by eye) possibly 1s or even 10s of lines for every a/b to determine whether any fix was needed. Some said that that would be such a major change that it should not be done until there was a new major release, a Python 3 off in the then distant future. Well, that future is now. I half-jokingly suggested that the change be made on Guido's original timetable, but that the '2.5' that completed the change simply be relabeled '3.0'. I personally would have preferred that it had been completed in 2.5. But that did not happen and more changes were made once they were made, and here we are. 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] 2.7 Release? 2.7 == last of the 2.x line?
Zooko O'Whielacronx wrote: Folks: So, if you guys slip in your favorite new Python 3 feature into 2.7 and add a deprecation warning for your least favorite Python 2 misfeature, Just run with the -3 flag for warnings. Also see my response to Glyph. 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] Retrieve an arbitrary element from a setwithoutremoving it
[Steven D'Aprano] Anyway, given the level of opposition to the suggestion, I'm no longer willing to carry the flag for it. If anyone else -- perhaps the OP -- feels they want to take it any further, be my guest. [geremy condra] I've said before that I'd like there to be one, standard way of doing this. A function call- set.pick() seems reasonably named to me- is probably the cleanest way to do that. Absent that, an example in the docs that illustrates the preferred idiom would be great. Summarizing my opposition to a new set method: 1) there already are at least two succinct ways to get the same effect 2) those ways work with any container, not just sets 3) set implementations in other languages show that this isn't needed. 4) there is value to keeping the API compact 5) isn't needed for optimization (selecting the same value in a loop makes no sense) 6) absence of real-world code examples that would be meaningfully improved I would be happy to add an example to the docs so that this thread can finally end. Raymond ___ 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] Retrieve an arbitrary element from a setwithoutremoving it
Raymond Hettinger wrote: Summarizing my opposition to a new set method: 1) there already are at least two succinct ways to get the same effect 2) those ways work with any container, not just sets 3) set implementations in other languages show that this isn't needed. 4) there is value to keeping the API compact 5) isn't needed for optimization (selecting the same value in a loop makes no sense) 6) absence of real-world code examples that would be meaningfully improved I would be happy to add an example to the docs so that this thread can finally end. Please do! 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] Retrieve an arbitrary element from a setwithoutremoving it
Eric Smith wrote: Raymond Hettinger wrote: Summarizing my opposition to a new set method: 1) there already are at least two succinct ways to get the same effect 2) those ways work with any container, not just sets 3) set implementations in other languages show that this isn't needed. 4) there is value to keeping the API compact 5) isn't needed for optimization (selecting the same value in a loop makes no sense) 6) absence of real-world code examples that would be meaningfully improved Agreed I would be happy to add an example to the docs so that this thread can finally end. Please do! Yes! ___ 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] 2to3, 3to2: official status
Martin v. Löwis mar...@v.loewis.de writes: Ben Finney wrote: Martin v. Löwis mar...@v.loewis.de writes: Well, 3to2 would then be an option for you: use Python 3 as the source language. I was under the impression that 2to3 was officially supported as part of Python, but 3to2 was a third-party tool. […] Is it an official part of Python? No, the status is exactly as you describe it. Okay. It's probably best for anyone with their Python developer hat on (which, in this forum, is all the time for any Python developer) to make the status of 3to2 clear when recommending it to people concerned about future plans. -- \“Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.” —Richard | _o__) Stallman | Ben Finney ___ 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] 2to3, 3to2: official status
Hi Ben, On Wed, Nov 4, 2009 at 6:49 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Martin v. Löwis mar...@v.loewis.de writes: Ben Finney wrote: Martin v. Löwis mar...@v.loewis.de writes: Well, 3to2 would then be an option for you: use Python 3 as the source language. I was under the impression that 2to3 was officially supported as part of Python, but 3to2 was a third-party tool. […] Is it an official part of Python? No, the status is exactly as you describe it. Okay. It's probably best for anyone with their Python developer hat on (which, in this forum, is all the time for any Python developer) to make the status of 3to2 clear when recommending it to people concerned about future plans. Are you implying that we shouldn't recommend 3to2 to people wanting to develop in Py3k and back-translate to 2.x? Thanks, Collin Winter ___ 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] 2to3, 3to2: official status
Collin Winter coll...@gmail.com writes: On Wed, Nov 4, 2009 at 6:49 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Okay. It's probably best for anyone with their Python developer hat on (which, in this forum, is all the time for any Python developer) to make the status of 3to2 clear when recommending it to people concerned about future plans. Are you implying that we shouldn't recommend 3to2 to people wanting to develop in Py3k and back-translate to 2.x? No, I'm implying that mentioning Python 3, 3to2, and 2to3 all together in a discussion about how to migrate can easily give the false impression that they're all equally supported by the Python developers. That 3to2 is *not* supported officially is certainly something I'd want to know if a Python core developer was recommending it to me to reassure me about the migration path to Python 3, and I didn't get that impression from the way it's been casually referenced in this discussion. -- \ “Never express yourself more clearly than you are able to | `\ think.” —Niels Bohr | _o__) | Ben Finney ___ 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
