Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Georg Brandl gmx.net> writes: > Agreed. Vinay, please either let me know when this is rectified (see also > Nick's request about reverting #12394 specific parts of the commit), or > revert the whole PEP 405 implementation for now, if the time is too short: > I don't want to delay the alpha much longer. There is still time until > beta after all. I didn't put any of the #12394 functionality into the PEP 405 work that I committed; the pysetup3.exe was data - the scripts that are installed to a venv - and I just overlooked it. That has now been rectified in 01381723bc50 - the .exe is gone. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] 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 405 (Python Virtual Environments) and Windows script support
Nick Coghlan gmail.com> writes: > In that case: Vinay, please revert everything from the pyvenv commit > that was actually related to issue #12394 rather than being part of > the PEP 405 implementation. As Carl says, it's an unrelated change > that needs to be discussed separately. There's nothing in there related to #12394 - just a pysetup3.exe file, which I had originally overlooked and have now removed. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] 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 405 (Python Virtual Environments) and Windows script support
Mark Hammond gmail.com> writes: > I don't understand the relationship between this "stock launcher" and > the PEP 397 launcher. They seem to have quite distinct requirements > without much overlap. Specifically, I'm not aware that the current PEP > 397 implementation could perform the same role as the "stock launcher" - > IIUC, it has no special handling of the "-script" suffix or special > logic based around its argv[0]. > Actually the stock launcher's job is similar to the 397 launcher, though it doesn't address many of the things that are in PEP 397. The basic requirement is to run the correct Python for a script installed as part of a package; that's done by having shebang lines (set up during installation) which point to the correct Python. The stock launcher reads the shebang line and invokes the appropriate Python. It's a reimplementation of the launcher used in setuptools and a much simplified version of the 397 launcher, which I put together when exploring how packaging would work with venvs on Windows. In theory, if the PEP 397 launcher is installed, you don't need the stock launcher; any script installed by packaging (or setuptools/Distribute) in a venv should have the correct shebang line, and the PEP 397 launcher should do the right thing. I'm sorry for all the confusion I've caused here :-( Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] 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: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args
Since this changeset, building on Windows seems to be broken (see http://python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/450 for example). Nadeem ___ Python-Dev mailing list [email protected] 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: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args
2012/5/29 Nadeem Vawda : > Since this changeset, building on Windows seems to be broken (see > http://python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/450 > for example). The following changesets should fix the two errors, but not warnings. changeset: 77231:df0144f68d76 tag: tip user:Victor Stinner date:Tue May 29 18:53:56 2012 +0200 files: Objects/unicodeobject.c description: Issue #14744: Fix compilation on Windows (part 2) changeset: 77230:6abab1a103a6 user:Victor Stinner date:Tue May 29 18:51:10 2012 +0200 files: Objects/longobject.c description: Issue #14744: Fix compilation on Windows Victor ___ Python-Dev mailing list [email protected] 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: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args
On 29 May 2012 17:55, Victor Stinner wrote: > 2012/5/29 Nadeem Vawda : >> Since this changeset, building on Windows seems to be broken (see >> http://python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/450 >> for example). > > The following changesets should fix the two errors, but not warnings. > > changeset: 77231:df0144f68d76 > tag: tip > user: Victor Stinner > date: Tue May 29 18:53:56 2012 +0200 > files: Objects/unicodeobject.c > description: > Issue #14744: Fix compilation on Windows (part 2) > > > changeset: 77230:6abab1a103a6 > user: Victor Stinner > date: Tue May 29 18:51:10 2012 +0200 > files: Objects/longobject.c > description: > Issue #14744: Fix compilation on Windows Build worked, there are still a couple of test failures, but they are in test_venv and test_logging. http://www.python.org/dev/buildbot/builders/x86%20XP-5%203.x/builds/456/steps/test/logs/stdio Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What should we do with cProfile?
Hello, As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out. So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes. I am willing to volunteer to push the change though if it is still desired by the community. Cheers! http://bugs.python.org/issue2919 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Unicode strings in Python 3.3
Hi, > * Use a Py_UCS4 buffer and then convert to the canonical form (ASCII, > UCS1 or UCS2). Approach taken by io.StringIO. io.StringIO is not only > used to write, but also to read and so a Py_UCS4 buffer is a good > compromise. > * PyAccu API: optimized version of chunks=[]; for ...: ... > chunks.append(text); return ''.join(chunks). > * Two steps: compute the length and maximum character of the output > string, allocate the output string and then write characters. str%args > was using it. > * Optimistic approach. Start with a ASCII buffer, enlarge and widen > (to UCS2 and then UCS4) the buffer when new characters are written. > Approach used by the UTF-8 decoder and by str%args since today. I ran extensive benchmarks on these 4 methods for str%args and str.format(args). The "two steps" method is not promising: parsing the format string twice is slower than other methods. The PyAccu API is faster than a Py_UCS4 buffer to concatenate a lot of strings, but it is slower in many other cases. I implemented the last method as the new internal "_PyUnicodeWriter" API: resize / widen the string buffer when writing new characters. I implemented more optimizations: * overallocate the buffer to limit the cost of realloc() * write characters directly in the buffer, avoid temporary buffers when possible (it is possible in most cases) * disable overallocation when formating the last argument * don't copy by value but copy by reference if the result is just a string (optimization already implemented indirectly in the PyAccu API) The _PyUnicodeWriter is the fastest method: it gives a speed up of 30% over the Py_UCS4 / PyAccu in general, and from 60% to 100% in some specific cases! I also compared str%args and str.format() with Python 2.7 (byte strings), 3.2 (UTF-16 or UCS-4) and 3.3 (PEP 393): Python 3.3 is as fast as Python 2.7 and sometimes faster! (Whereras Python 3.2 is 10 to 30% slower than Python 2 in general) -- I wrote a tool to run benchmarks and to compare results: https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py https://bitbucket.org/haypo/misc/src/tip/python/bench_str.py Run the benchmark: ./python benchmark.py --file=FILE script bench_str.py Compare results: ./python benchmark.py compare_to FILE1 FILE2 FILE3 ... -- Python 2.7 vs 3.2 vs 3.3: http://bugs.python.org/file25685/REPORT_32BIT_2.7_3.2_writer http://bugs.python.org/file25687/REPORT_64BIT_2.7_3.2_writer http://bugs.python.org/file25757/report_windows7 Warning: For the Windows benchmark, Python 3.3 is compiled in 32 bits, whereas 2.7 and 3.2 are compiled in 64 bits (formatting integers is slower in 32 bits). -- UCS4 vs PyAccu vs _PyUnicodeWriter: http://bugs.python.org/file25686/REPORT_32BIT_3.3 http://bugs.python.org/file25688/REPORT_64BIT_3.3 Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Unicode strings in Python 3.3
On Wed, May 30, 2012 at 8:44 AM, Victor Stinner wrote: > I also compared str%args and str.format() with Python 2.7 (byte > strings), 3.2 (UTF-16 or UCS-4) and 3.3 (PEP 393): Python 3.3 is as > fast as Python 2.7 and sometimes faster! (Whereras Python 3.2 is 10 to > 30% slower than Python 2 in general) Very cool news! Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What should we do with cProfile?
Alexandre Vassalotti wrote: Hello, As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out. So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes. I am willing to volunteer to push the change though if it is still desired by the community. I don't have a strong opinion either way, but if it was worth merging them for 3.3, then it's worth merging them for 3.4. Don't let "I won't be finished in time for 3.3" stop you. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
On 5/28/2012 10:59 PM, Terry Reedy wrote: On 5/28/2012 9:48 PM, Brian Curtin wrote: > You should probably not have a bare except Idle code already has many of them At least 29 by grep. After further discussion, Roger Serwy and I have agreed that we should start reducing that number rather than increasing it. There is a nearby 'except:' that I believe should be 'except AttributeError:'. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What should we do with cProfile?
>> As per PEP 3108, we were supposed to merge profile/cProfile into one >> unified module. I initially championed the change, but other things got in >> the way and I have never got to the point of a useful patch. I posted some >> code and outlined an approach how the merge could be done. However, there >> still a lot of details to be worked out. >> >> So I wondering whether we should abandon the change all together or >> attempt >> it for the next release. Personally, I slightly leaning on the former >> option since the two modules are actually fairly different underneath even >> though they are used similarly. And also, because it is getting late to >> make such backward incompatible changes. >> >> I am willing to volunteer to push the change though if it is still desired >> by the community. > > > > I don't have a strong opinion either way, but if it was worth merging them > for 3.3, then it's worth merging them for 3.4. Don't let "I won't be > finished in time for 3.3" stop you. > +1 IMHO merging modules with their C accelerators is a worthy goal, because having two modules in the stdlib doing the same is confusing. At worst, the merged module can do everything it can in C and defer the things it can't do to Python (or defer *everything* on platforms where the C extension can't be built for some reason). And as Steven said, the 3.3 timeline doesn't have anything really special about it. Although there's still time until the beta release, even if this is done for 3.4 it will be great. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What should we do with cProfile?
On Wed, May 30, 2012 at 1:01 PM, Eli Bendersky wrote: > And as Steven said, the 3.3 timeline doesn't have anything really > special about it. Although there's still time until the beta release, > even if this is done for 3.4 it will be great. Yep - there's a reason the 3.4 target gets added to the tracker even before 3.3 is out. It's precisely so we can bump things as soon as we reach a point where we're comparing the effort we think is needed to get them agreed on and/or bedded down properly and the time remaining before the first beta and officially say "not going to happen". I've already done that for Eugene Toder's proposed compiler enhancements. It's a promising approach, but it's *way* too late in the 3.3 cycle to be contemplating that kind of change. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Unicode strings in Python 3.3
On 5/29/2012 3:51 PM, Nick Coghlan wrote: On Wed, May 30, 2012 at 8:44 AM, Victor Stinner wrote: I also compared str%args and str.format() with Python 2.7 (byte strings), 3.2 (UTF-16 or UCS-4) and 3.3 (PEP 393): Python 3.3 is as fast as Python 2.7 and sometimes faster! (Whereras Python 3.2 is 10 to 30% slower than Python 2 in general) Very cool news! Cheers, Nick. Very cool indeed! Thanks, Victor. I have programs that are just full of formatting operations, that will benefit from this work. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Property inheritance in Python
Hi, I apologize if I violate (or am violating) some sacred mailing list rules. Torsten wrote back in 2010 (http://mail.python.org/pipermail/python-dev/2010-April/099672.html) about property inheritance behavior and super(). Specifically, only fget() behavior of properties work with super(), not fset() or fdel(). I apologize if there's some obvious reason this has not been addressed since then, but it seems to be expected behavior and most Pythonic, and confused me greatly when I ran into it recently. Torsten's original thread seems to have gone as if unseen, so I hesitantly bump this topic in the hopes of a resolution. Thanks, Allen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows (part 2)
Am 29.05.2012 18:54, schrieb victor.stinner: > http://hg.python.org/cpython/rev/df0144f68d76 > changeset: 77231:df0144f68d76 > user:Victor Stinner > date:Tue May 29 18:53:56 2012 +0200 > summary: > Issue #14744: Fix compilation on Windows (part 2) All Windows buildbots are still failing the test suite, with an "invalid format string" ValueError, so I assume that is related to your string formatting speedups -- can you please have a look at it before I can tag the alpha? thanks, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Property inheritance in Python
On 5/30/2012 1:58 AM, [email protected] wrote: Hi, I apologize if I violate (or am violating) some sacred mailing list rules. Torsten wrote back in 2010 (http://mail.python.org/pipermail/python-dev/2010-April/099672.html) about property inheritance behavior and super(). Specifically, only fget() behavior of properties work with super(), not fset() or fdel(). I apologize if there's some obvious reason this has not been addressed since then, but it seems to be expected behavior and most Pythonic, and confused me greatly when I ran into it recently. Torsten's original thread seems to have gone as if unseen, so I hesitantly bump this topic in the hopes of a resolution. This sort of idea should either be posted on python-ideas to get support or put on the tracker if the proposal is specific enough to write a patch (or both, with a patch making it more likely to happen). -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
