Contact information for Jim Hugunin?
Does anybody have an email address (or anything, really) for Jim Hugunin? He left Google in May and appears to have dropped off the face of the internet. Please email me privately. I swear I will use the information only for good and never for evil, //arry/ -- http://mail.python.org/mailman/listinfo/python-list
Announcing a new podcast: Radio Free Python
Radio Free Python is a new monthly podcast focused on Python and its community. Episode 1 has just been released! It features a panel discussion with the PythonLabs team: * Barry Warsaw, * Fred Drake, * Guido van Rossum, * Roger Masse, * and Tim Peters. You can find it at http://www.radiofreepython.com/ as of this very minute. Enjoy! /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Python language changes that first shipped in something besides CPython?
I'm doing a talk at PyCon about changes to the Python language. I'm wondering: are there any Python language changes that first shipped in an implementation of Python besides CPython? The sort of answer I'm looking for: "set literals first shipped in Jython 2.2, six months before they shipped in CPython 2.3". (Note that that specific answer is wrong in every important detail.) /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Nested inner classes and inheritance -> namespace problem
The problem: if you're currently in a nested class, you can't look up variables in the outer "class scope". For example, this code fails in Python 3: class Outer: class Inner: class Worker: pass class InnerSubclass(Inner): class Worker(Inner.Worker): pass It fails at the definition of Worker inside InnerSubclass. Python 3 can't find "Inner", in order to get to "Inner.Worker". Adding "global Inner" just above that line doesn't help--it's not a global. Adding "nonlocal Inner" just above that line doesn't help either--I suppose it's the /wrong kind/ of nonlocal. nonlocal is for nested functions, and this uses nested classes. You can tell me YAGNI, but I tripped over this because I wanted it. It's not a contrived example. I actually use inner classes a lot; I suppose I'm relatively alone in doing so. Yes, I could make the problem go away if I didn't have nested inner classes like this. But I like this structure. Any idea how I can make it work while preserving the nesting and inheritance? Thanks, /larry/ // -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested inner classes and inheritance -> namespace problem
On 04/13/2011 07:37 PM, Eric Snow wrote: I suppose you could try something like this: class Outer: global Inner class Inner: class Worker: pass class InnerSubclass(Inner): class Worker(Inner.Worker): pass However, that pollutes your global namespace. If you are worried about that you could try: [...] It also means that Inner is not actually /in/ Outer, and the whole point was to have the class accessed as Outer.Inner. But I can get what I wanted, if immediately after the definition of Outer I have: Outer.Inner = Inner del Inner Thanks for the suggestion of "global Inner"! That makes this approach palatable. /larry/ -- http://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.8rc1 and Python 3.5.5rc1 are now available
On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.8rc1 and Python 3.5.5rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8rc1 here: https://www.python.org/downloads/release/python-348rc1/ And you can find Python 3.5.5rc1 here: https://www.python.org/downloads/release/python-355rc1/ Happy Pythoning, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.8 and Python 3.5.5 are now available
On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.8 and Python 3.5.5. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8 here: https://www.python.org/downloads/release/python-348/ And you can find Python 3.5.5 here: https://www.python.org/downloads/release/python-355/ Happy Pythoning, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.8 and Python 3.5.5 are now available
Actually, it was updated on the server, but somehow the old version was sticking around in the CDN cache. I "purged" it and it's fine now. Weird that it would linger this long! Cheers, //arry/ On 02/10/2018 03:20 AM, Serhiy Storchaka wrote: 05.02.18 02:35, Larry Hastings пише: On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.8 and Python 3.5.5. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8 here: https://www.python.org/downloads/release/python-348/ And you can find Python 3.5.5 here: https://www.python.org/downloads/release/python-355/ Online documentation for 3.5 is not updated yet. https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-5 -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.8 and Python 3.5.5 are now available
Actually, it was updated on the server, but somehow the old version was sticking around in the CDN cache. I "purged" it and it's fine now. Weird that it would linger this long! Cheers, //arry/ On 02/10/2018 03:20 AM, Serhiy Storchaka wrote: 05.02.18 02:35, Larry Hastings пише: On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.8 and Python 3.5.5. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8 here: https://www.python.org/downloads/release/python-348/ And you can find Python 3.5.5 here: https://www.python.org/downloads/release/python-355/ Online documentation for 3.5 is not updated yet. https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-5 -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.6rc1 and Python 3.5.3rc1 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.6rc1 and Python 3.5.6rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.3rc1 contains many incremental improvements over Python 3.5.2. Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.6rc1 here: https://www.python.org/downloads/release/python-346rc1/ And you can find Python 3.5.3rc1 here: https://www.python.org/downloads/release/python-353rc1/ Python 3.4.6 final and Python 3.5.3 final are both scheduled for release on January 16th, 2017. Happy New Year, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.6 and Python 3.5.3 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm delighted to announce the availability of Python 3.4.6 and Python 3.5.3. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.3 contains many incremental improvements over Python 3.5.2. There were literally no code changes between rc1 and final for either release. The only change--apart from the necessary updates from "rc1" to final--was a single copyright notice update for one of the OS X ".plist" property list files in 3.5.3 final. You can find Python 3.5.3 here: https://www.python.org/downloads/release/python-353/ And you can find Python 3.4.6 here: https://www.python.org/downloads/release/python-346/ Best wishes, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.9rc1 and Python 3.5.6rc1 are now available
On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.9rc1 and Python 3.5.6rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9rc1 here: https://www.python.org/downloads/release/python-349rc1/ And you can find Python 3.5.6rc1 here: https://www.python.org/downloads/release/python-356rc1/ Python's entrenched bureaucracy soldiers on, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.9 and Python 3.5.6 are now available
On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9 here: https://www.python.org/downloads/release/python-349/ And you can find Python 3.5.6 here: https://www.python.org/downloads/release/python-356/ We now return you to your pitched debate already in progress, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.5rc1 and Python 3.5.2rc1 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.5rc1 and Python 3.5.2rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes made to Python 3.4 since Python 3.4.4 should be security fixes only; conventional bug fixes are not accepted. Also, Python 3.4.5rc1 and all future releases of Python 3.4 will only be released as source code--no official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.2rc1 contains many incremental improvements over Python 3.5.1. Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.5rc1 here: https://www.python.org/downloads/release/python-345rc1/ And you can find Python 3.5.2rc1 here: https://www.python.org/downloads/release/python-352rc1/ Python 3.4.5 final and Python 3.5.2 final are both scheduled for release on June 26th, 2016. Happy Pythoneering, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.10rc1 and Python 3.5.7rc1 are now available
On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.4.10rc1 and Python 3.5.7rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. The "final" releases on both these branches should be out in about two weeks. Of particular note: that release of Python 3.4, Python 3.4.10 final, will be the final release ever in the Python 3.4 series. After 3.4.10, the branch will be closed for good and I'll retire as Python 3.4 Release Manager. I'll still be the Python 3.5 Release Manager until 3.5 similarly concludes, approximately eighteen months from now. You can find Python 3.4.10rc1 here: https://www.python.org/downloads/release/python-3410rc1/ And you can find Python 3.5.7rc1 here: https://www.python.org/downloads/release/python-357rc1/ Best wishes, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Python 3.5.7 is now available
On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.5.7. Python 3.5 is in "security fixes only" mode. It only accepts security fixes, not conventional bug fixes, and the release is source-only. And you can find Python 3.5.7rc1 here: https://www.python.org/downloads/release/python-357/ Best wishes, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Python 3.4.10 is now available
On behalf of the Python development community, I'm proud--if slightly sad--to announce the availability of Python 3.4.10. Python 3.4.10 was released in "security fixes only" mode. It only contains security fixes, not conventional bug fixes, and it is a source-only release. Python 3.4.10 is the final release in the Python 3.4 series. As of this release, the 3.4 branch has been retired, no further changes to 3.4 will be accepted, and no new releases will be made. This is standard Python policy; Python releases get five years of support and are then retired. If you're still using Python 3.4, you should consider upgrading to the current version--3.7.2 as of this writing. Newer versions of Python have many new features, performance improvements, and bug fixes, which should all serve to enhance your Python programming experience. We in the Python core development community thank you for your interest in 3.4, and we wish you all the best! You can find Python 3.4.10 here: https://www.python.org/downloads/release/python-3410/ One I completely finish the Python 3.4.10 release process, I will retire as Python 3.4 Release Manager. I'll still be Python 3.5 Release Manager for another eighteen months or so. Python 3.4 is OVER! https://www.youtube.com/watch?v=YlGqN3AKOsA //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Farewell, Python 3.4
It's with a note of sadness that I announce the final retirement of Python 3.4. The final release was back in March, but I didn't get around to actually closing and deleting the 3.4 branch until this morning. Python 3.4 introduced many features we all enjoy in modern Python--the asyncio, ensurepip, and enum packages, just to name three. It's a release I hope we all remember fondly. My eternal thanks to all the members of the release team that worked on Python 3.4: Georg Brandl Julien Palard Martin von Löwis Ned Deily Steve Dower Terry Reedy and all the engineers of the Python infrastructure team. Special thanks to Benjamin Peterson and Ned Deily, who frequently scurried around behind the scenes cleaning up the messes I cluelessly left in my wake. Having closed 3.4, I am now retired as Python 3.4 Release Manager. I regret to inform all of you that you're still stuck with me as Python 3.5 Release Manager until sometime next year. My very best wishes, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.8rc1 is released
On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.5.8rc1. Python 3.5 is in "security fixes only" mode. This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. You can find Python 3.5.8rc1 here: https://www.python.org/downloads/release/python-358rc1/ I think Python 3.5 may just barely outlive 2.7, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.8rc2 is released
On behalf of the Python development community, I'm relieved to announce the availability of Python 3.5.8rc2. It's been a month after Python 3.5.8rc1, and since then we've added a small amount of new code to fix an API-level regression in http client, updated expat to 2.2.8, and upgraded the required version of Sphinx from 1.2 to 1.8. This is enough change that I feel a second rc is indicated. Assuming all is quiet, 3.5.8 final should come out in about two weeks. This new version is a source-only release. You can find Python 3.5.8rc2 here: https://www.python.org/downloads/release/python-358rc2/ Hullo from PyCon IE, /arry -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.8 is (finally) released
On behalf of the Python development community, I'm relieved to announce the availability of Python 3.5.8. Python 3.5 is in "security fixes only" mode. This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. You can find Python 3.5.8 here: https://www.python.org/downloads/release/python-358/ Oh what fun, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version
Due to awkward CDN caching, some users who downloaded the source code tarballs of Python 3.5.8 got a preliminary version instead of the final version. As best as we can tell, this only affects the .xz release; there are no known instances of users downloading an incorrect version of the .tgz file. If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours of its release, you might be affected. It's easy to determine this for yourself. The file size (15,382,140 bytes) and MD5 checksum (4464517ed6044bca4fc78ea9ed086c36) published on the release page have always matched the correct version. Also, the GPG signature file will only report a "Good signature" for the correct .xz file (using "gpg --verify"). What's the difference between the two? The only difference is that the final version also merges a fix for Python issue tracker #38243: https://bugs.python.org/issue38243 The fix adds a call to "html.escape" at a judicious spot, line 896 in Lib/xmlrpc/server.py. The only other changes are one new test, to ensure this new code is working, and an entry in the NEWS file. You can see the complete list of changes here: https://github.com/python/cpython/pull/16516/files What should you do? It's up to you. * If you and your users aren't using the XMLRPC library built in to Python, you don't need to worry about which version of 3.5.8 you downloaded. * If you downloaded the .tgz tarball or the Git repo, you already have the correct version. * If you downloaded the xz file and want to make sure you have the fix, check the MD5 sum, and if it's wrong download a fresh copy (and make sure that one matches the known good MD5 sum!). To smooth over this whole sordid mess, I plan to make a 3.5.9 release in the next day or so. It'll be identical to the 3.5.8 release; its only purpose is to ensure that all users have the same updated source code, including the fix for #38243. Sorry for the mess, everybody, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.9 is released
On behalf of the Python development community, I'm slightly chagrined to announce the availability of Python 3.5.9. There were no new changes in version 3.5.9; 3.5.9 was released only because of a CDN caching problem, which resulted in some users downloading a prerelease version of the 3.5.8 .xz source tarball. Apart from the version number, 3.5.9 is identical to the proper 3.5.8 release. This new version is a source-only release. You can find Python 3.5.9 here: https://www.python.org/downloads/release/python-359/ Happy Halloween, /arry -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.10rc1 is released
On behalf of the Python development community, I'm pleased to finally announce the availability of Python 3.5.10rc1. Python 3.5 is in "security fixes only" mode. This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. Important Notice: The latest releases of Linux (Ubuntu 20.04, Fedora 32) ship with a new version of OpenSSL. New versions of OpenSSL often include upgraded configuration requirements to maintain network security; this new version no longer finds Python 3.5's OpenSSL configuration acceptable. As a result, most or all secure-transport networking libraries are broken in this release on systems where this new version of OpenSSL is deployed. This means, for example, that seven (7) of the regression tests in the test suite now regularly fail. Older versions of Linux, with older versions of OpenSSL installed, are unaffected. We're aware of the problem. Unfortunately, as 3.5 is nearly completely out of support, it has become very low priority, and we've been unable to find the resources to get the problem fixed. It's possible that these problems simply won't be fixed in 3.5 before it reaches its end-of-life. As always we recommend upgrading to the latest Python release wherever possible. You can find Python 3.5.10rc1 here: https://www.python.org/downloads/release/python-3510rc1/ Cheers, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.10 is released
On behalf of the Python development community, I'm plesed to announce the availability of Python 3.5.10. Python 3.5 is in "security fixes only" mode. This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. Important Notice: The latest releases of Linux (Ubuntu 20.04, Fedora 32) ship with a new version of OpenSSL. New versions of OpenSSL often include upgraded configuration requirements to maintain network security; this new version no longer finds Python 3.5's OpenSSL configuration acceptable. As a result, most or all secure-transport networking libraries are broken in this release on systems where this new version of OpenSSL is deployed. This means, for example, that seven (7) of the regression tests in the test suite now regularly fail. Older versions of Linux, with older versions of OpenSSL installed, are unaffected. We're aware of the problem. Unfortunately, as 3.5 is nearly completely out of support, it has become very low priority, and we've been unable to find the resources to get the problem fixed. It's possible that these problems simply won't be fixed in 3.5 before it reaches its end-of-life. As always we recommend upgrading to the latest Python release wherever possible. Python 3.5 will reach its "end of life" at the end of September 2020. If there are no security patches filed for Python 3.5 after the release of Python 3.5.10, then Python 3.5.10 will be the final release of the 3.5 series. You can find Python 3.5.10 here: https://www.python.org/downloads/release/python-3510/ Cheers, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Our Luxurious, Rubinesque, Python 2.4
I finally got 'round to installing Python 2.4. I'm planning on using Python for downloadable software, where every kilobyte counts and smaller is definitely better. Imagine my surprise when I looked up python24.dll and found SWEET JUMPING CHRISTMAS it's ballooned up to 1.8MB! This isn't a deal-killer outright. But python23.dll is 1.0MB, svelte by comparison. Can someone tell me what made it 80% larger? Also, how much would I be able to trim away if I recompiled it myself? Is a lot of it native implementations of Python libraries that I might not care about including, or is it all fundamental VM stuff that couldn't possibly be removed? Thanks, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0b1
On behalf of the Python development team, it's my privilege to announce
the first beta release of Python 3.4.
This is a preview release, and its use is not recommended for
production settings.
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes. Major new features and
changes in the 3.4 release series include:
* PEP 435, a standardized "enum" module
* PEP 436, a build enhancement that will help generate introspection
information for builtins
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
in subprocesses
* PEP 450, a new "statistics" module
* PEP 453, a bundled installer for the *pip* package manager
* PEP 456, a new hash algorithm for Python strings and binary data
* PEP 3154, a new and improved protocol for pickled objects
* PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O
Python 3.4 is now in "feature freeze", meaning that no new features will be
added. The final release is projected for late February 2014.
To download Python 3.4.0b1 visit:
http://www.python.org/download/releases/3.4.0/
Please consider trying Python 3.4.0b1 with your code and reporting any
new issues you notice to:
http://bugs.python.org/
Enjoy!
--
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)
--
https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.0b1
On 11/24/2013 02:00 PM, Larry Hastings wrote: Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: Whoops, sorry, I missed a couple of PEPs there: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 451, standardizing module metadata for Python's module import system * PEP 454, a new "tracemalloc" module for tracing Python memory allocations They're on the web site already, and they'll be in the next announcement. Sorry for the oversight! //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0b2
On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for late February 2014. To download Python 3.4.0b2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0b3
On behalf of the Python development team, I'm quite pleased to announce the third beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. To download Python 3.4.0b3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0 release candidate 1
On behalf of the Python development team, I'm delighted to announce the first release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. To download Python 3.4.0rc1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc1 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.1 and 3.4.4rc1 are now available
On behalf of the Python development community and the Python 3.4 and 3.5 release teams, I'm pleased to announce the simultaneous availability of Python 3.5.1 and Python 3.4.4rc1. As point releases, both have many incremental improvements over their predecessor releases. You can find Python 3.5.1 here: https://www.python.org/downloads/release/python-351/ And you can find Python 3.4.4rc1 here: https://www.python.org/downloads/release/python-344rc1/ Python 2.7.11 shipped today too, so it's a Python release-day hat trick! Happy computing, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.4 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.4. Python 3.4.4 is the last version of Python 3.4.4 with binary installers, and the end of "bugfix" support. After this release, Python 3.4.4 moves into "security fixes only" mode, and future releases will be source-code-only. You can see what's changed in Python 3.4.4 (as compared to previous versions of 3.4) here: https://docs.python.org/3.4/whatsnew/changelog.html#python-3-4-4 And you can download Python 3.4.4 here: https://www.python.org/downloads/release/python-344/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. One final note. 3.4.4 final marks the end of an era: it contains the last Windows installers that will be built by Martin von Loewis. Martin has been the Windows release "Platform Expert" since the Python 2.4 release cycle started more than twelve years ago--in other words, for more than half of Python's entire existence! On behalf of the Python community, and particularly on behalf of the Python release managers, I'd like to thank Martin for his years of service to the community, and for the care and professionalism he brought to his role. It was a pleasure working with him, and we wish him the very best in his future projects. We hope you enjoy Python 3.4.4! Happy holidays, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.4.3rc1 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm happy to announce the availability of Python 3.4.3rc1. Python 3.4.3rc1 has many bugfixes and other small improvements over 3.4.2. You can download it here: https://www.python.org/download/releases/3.4.3 Not done yet, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.5.0a1 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm also pleased to announce the availability of Python 3.5.0a1. Python 3.5.0a1 is the first alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development, and is far from complete. This is a preview release, and its use is not recommended for production settings. You can download it here: https://www.python.org/download/releases/3.5.0a1 Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASE] Python 3.4.3rc1 is now available
On 02/08/2015 02:06 PM, Mark Lawrence wrote: On 08/02/2015 22:00, Larry Hastings wrote: On behalf of the Python development community and the Python 3.4 release team, I'm happy to announce the availability of Python 3.4.3rc1. Python 3.4.3rc1 has many bugfixes and other small improvements over 3.4.2. You can download it here: https://www.python.org/download/releases/3.4.3 Not done yet, //arry/ The link provided took me to 3.4.1 not 3.4.3rc1. Yeah, I made some sort of weird copy-and-paste error with the link. But if you type in https://www.python.org/download/releases/3.4.3 into your browser it works fine. Sorry for the inconvenience, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.3 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.3. Python 3.4.3 has many bugfixes and other small improvements over 3.4.2. You can find it here: https://www.python.org/downloads/release/python-343/ The release slipped by two or three days, depending on what time zone you're in. This is my fault--I apologize for the inconvenience. Cheers, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0 release candidate 2 is now available
On behalf of the Python development team, I'm delighted to announce the second and final release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. The python.org web site has recently been updated to something completely new, and I'm having some difficulty updating it. For now I've made Python 3.4.0rc2 available on the legacy web site: http://legacy.python.org/download/releases/3.4.0/ Once I can update the new web site, Python 3.4.0rc2 will be available here: http://python.org/download/releases/ (I'm not sure what the final URL will be, but you'll see it listed on that page.) Please consider trying Python 3.4.0rc2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0 release candidate 3
On behalf of the Python development team, I'm pleased to announce the third and final** release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for March 16, 2014. To download Python 3.4.0rc3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! ** This time we really mean it! No foolin'! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0
On behalf of the Python development team, I'm thrilled to announce the official release of Python 3.4. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O To download Python 3.4.0 visit: http://www.python.org/download/releases/3.4.0/ This is a production release. Please report any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.1rc1
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.1rc1. Python 3.4.1rc1 has over three hundred bugfixes and other improvements over 3.4.0. One notable change: the version of OpenSSL bundled with the Windows installer no longer has the "HeartBleed" vulnerability. You can download it here: https://www.python.org/download/releases/3.4.1 One note: the "topics" data file for the pydoc is broken in this release. This means the pydoc command and the built-in "help" will fail on some topics. //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.1
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.1. Python 3.4.1 has over three hundred bugfixes and other improvements over 3.4.0. One notable change: the version of OpenSSL bundled with the Windows installer no longer has the "HeartBleed" vulnerability. You can download it here: https://www.python.org/download/releases/3.4.1 //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0a2
On behalf of the Python development team, I'm chuffed to announce the second alpha release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 435, a standardized "enum" module * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 447, a new magic method for metaclasses (``__typelookup__``) * PEP 448, making automatic sequence unpacking more general To download Python 3.4.0a2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a2 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.0a2
On 09/09/2013 09:30 PM, Antoine Pitrou wrote: Le Mon, 9 Sep 2013 08:16:06 -0400, Brett Cannon a écrit : Those last two PEPs are still in draft form and not accepted nor have any committed code yet. Unless Larry enthusiastically sneaked them into the release. Whoops. Nope, I'm not that enthusiastic. I'll remove it from the web site, but obviously I can't do anything about the announcement. //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0a3
On behalf of the Python development team, I'm pleased to announce the third alpha release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 435, a standardized "enum" module * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses To download Python 3.4.0a3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a3 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0a4
On behalf of the Python development team, I'm very pleased to announce the fourth and final alpha release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, the new "statistics" module * PEP 3156, the new "asyncio" module, a new framework for asynchronous I/O To download Python 3.4.0a4 visit: http://www.python.org/download/releases/3.4.0/ Python 3.4.0a4 has several known issues: * The Python compiler has a small memory leak. * The "asyncio" module test suite fails on some platforms. * I/O conducted by the "asyncio" module may, rarely, erroneously time out. The timeout takes one hour. Please consider trying Python 3.4.0a4 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0a2 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a2. Python 3.5.0a2 is the second alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development, and is far from complete. This is a preview release, and its use is not recommended for production settings. Two important notes for Windows users about Python 3.5.0a2: * If you have previously installed Python 3.5.0a1, you must manually uninstall it before installing Python 3.5.0a2 (issue23612). * If installing Python 3.5.0a2 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. You can find Python 3.5.0a2 here: https://www.python.org/downloads/release/python-350a2/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0a3 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a3. Python 3.5.0a3 is the third alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development, and is far from complete. This is a preview release, and its use is not recommended for production settings. Two important notes for Windows users about Python 3.5.0a3: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0a3 (issue23612). * If installing Python 3.5.0a3 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. You can find Python 3.5.0a3 here: https://www.python.org/downloads/release/python-350a3/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0a4 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a4. Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under development, and is not yet complete. This is a preview release, and its use is not recommended for production settings. The next release of Python 3.5 will be 3.5.0b1, the first beta release. Python 3.5 will enter "feature freeze" at this time; no new features will be added to 3.5 after this point. Python 3.5.0b1 is scheduled to be released May 22, 2015. Three important notes for Windows users about Python 3.5.0a4: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0a4 (issue23612). * If installing Python 3.5.0a4 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows installer for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable installer designed to be run as part of a larger application's installer for apps using or extending Python. You can find Python 3.5.0a4 here: https://www.python.org/downloads/release/python-350a4/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0b1 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.0b1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. (However, there are a handful of features that weren't quite ready for Python 3.5.0 beta 1; these were granted exceptions to the freeze, and are scheduled to be added before beta 2.) This is a preview release, and its use is not recommended for production settings. Three important notes for Windows users about Python 3.5.0b1: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0b1 (issue23612). * If installing Python 3.5.0b1 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows build for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable release designed to be deployed as part of a larger application's installer for apps using or extending Python. During the 3.5 alpha releases, this was an executable installer; as of 3.5.0 beta 1 the embeddable build of Python is now shipped in a zip file. You can find Python 3.5.0b1 here: https://www.python.org/downloads/release/python-350b1/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0b2 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0b2. Python 3.5.0b1 had a major regression (see http://bugs.python.org/issue24285 for more information) and as such was not suitable for testing Python 3.5. Therefore we've made this extra beta release, only a week later. Anyone trying Python 3.5.0b1 should switch immediately to testing with Python 3.5.0b2. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. (However, there are a handful of features that weren't quite ready for Python 3.5.0 beta 2; these were granted exceptions to the freeze, and are scheduled to be added before beta 3.) This is a preview release, and its use is not recommended for production settings. Three important notes for Windows users about Python 3.5.0b2: * If installing Python 3.5.0b2 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows build for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable release designed to be deployed as part of a larger application's installer for apps using or extending Python. During the 3.5 alpha releases, this was an executable installer; as of 3.5.0 beta 1 the embeddable build of Python is now shipped in a zip file. You can find Python 3.5.0b2 here: https://www.python.org/downloads/release/python-350b2/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0b3 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0b3. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. This is a preview release, and its use is not recommended for production settings. An important reminder for Windows users about Python 3.5.0b3: if installing Python 3.5.0b2 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. You can find Python 3.5.0b2 here: https://www.python.org/downloads/release/python-350b3/ Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0b4 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm delighted to announce the availability of Python 3.5.0b4. Python 3.5.0b4 is scheduled to be the last beta release; the next release will be Python 3.5.0rc1, or Release Candidate 1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. This is a preview release, and its use is not recommended for production settings. An important reminder for Windows users about Python 3.5.0b4: if installing Python 3.5.0b4 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. You can find Python 3.5.0b4 here: https://www.python.org/downloads/release/python-350b4/ Happy hacking, */arry* -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0rc1 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc1, also known as Python 3.5.0 Release Candidate 1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc1 here: https://www.python.org/downloads/release/python-350rc1/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Happy hacking, /arry -- https://mail.python.org/mailman/listinfo/python-list
Re: Sorry folks, minor hiccup for Python 3.5.0rc1
On 08/10/2015 05:55 PM, Larry Hastings wrote: I yanked the tarballs off the release page as soon as I suspected something. I'm rebuilding the tarballs and the docs now. If you grabbed the tarball as soon as it appeared, it's slightly out of date, please re-grab. p.s. I should have mentioned--the Mac and Windows builds should be fine. They, unlike me, updated their tree ;-) -- https://mail.python.org/mailman/listinfo/python-list
Sorry folks, minor hiccup for Python 3.5.0rc1
I built the source tarballs with a slightly-out-of-date tree. We slipped the release by a day to get two fixes in, but the tree I built from didn't have those two fixes. I yanked the tarballs off the release page as soon as I suspected something. I'm rebuilding the tarballs and the docs now. If you grabbed the tarball as soon as it appeared, it's slightly out of date, please re-grab. Sorry for the palaver, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0rc2 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc2, also known as Python 3.5.0 Release Candidate 2. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc2 here: https://www.python.org/downloads/release/python-350rc2/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0rc3 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc3, also known as Python 3.5.0 Release Candidate 3. The next release of Python 3.5 will be Python 3.5.0 final. There should be few (or no) changes to Python 3.5 between rc3 and final. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc3 here: https://www.python.org/downloads/release/python-350rc3/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Happy hacking, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0rc4 is now available!
On behalf of the Python development community and the Python 3.5 release team, I'm surprised to announce the availability of Python 3.5.0rc4, also known as Python 3.5.0 Release Candidate 4. Python 3.5.0 Release Candidate 3 was only released about a day ago. However: during testing, a major regression was discovered, reported on the issue tracker as #25027: http://bugs.python.org/issue25027 Python 3.5 includes some big changes on how Python is built on Windows. One of those changes resulted in Python processes on Windows exceeding the maximum number of loadable shared libraries. As a result Windows builds of Python could no longer run major Python software stacks like Pandas and Jupyter. Fixing this required non-trivial last-minute changes to the Windows build--and those changes need testing. We therefore elected to insert an extra release candidate before the final release, to get these changes into your hands as soon as possible, so that Windows users could test these changes. As with all other Python 3.5 releases to date, this is a preview release, and its use is not recommended for production settings. However, users are encouraged to test with Python 3.5.0rc4, /especially/ Windows users who build or make use of numerous external packages. (Non-Windows users will find little difference between Python 3.5.0rc3 and Python 3.5.0rc4.) You can find Python 3.5.0rc4 here: https://www.python.org/downloads/release/python-350rc4/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Please kick the tires, //arry/ p.s. Special thanks from the Python 3.5 release team to Christoph Gohlke for the bug report! -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm proud to announce the availability of Python 3.5.0. Python 3.5.0 is the newest version of the Python language, and it contains many exciting new features and optimizations. You can read all about what's new in Python 3.5.0 here: https://docs.python.org/3.5/whatsnew/3.5.html And you can download Python 3.5.0 here: https://www.python.org/downloads/release/python-350/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. We hope you enjoy Python 3.5.0! //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.1rc1 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.1rc1. Python 3.5.1 will be the first update for Python 3.5. Python 3.5 is the newest version of the Python language, and it contains many exciting new features and optimizations. You can see what's changed in Python 3.5.1rc1 (as compared to 3.5.0) here: https://docs.python.org/3.5/whatsnew/changelog.html And you can download Python 3.5.1 here: https://www.python.org/downloads/release/python-351rc1/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. We hope you enjoy Python 3.5.1! //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.4.2rc1 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm chuffed to announce the availability of Python 3.4.2rc1. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the OS X installers are now distributed as signed installer package files compatible with the OS X Gatekeeper security feature. You can download it here: https://www.python.org/download/releases/3.4.2 Be seeing you, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASE] Python 3.4.2rc1 is now available
On 09/22/2014 03:58 PM, Victor Stinner wrote: Someone broke test_pydoc. Example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.4/builds/481/steps/test/logs/stdio I broke it while making the release. Known bug, happened before, for 3.4.1rc1. http://bugs.python.org/issue21431 We'll get it right for 3.4.2 final. I don't think we need to respin 3.4.2rc1 / add a 3.4.2rc2 for this. On 09/22/2014 06:02 PM, Terry Reedy wrote: On 9/22/2014 10:15 AM, Larry Hastings wrote: You can download it here: https://www.python.org/download/releases/3.4.2 Unfortunately, I cannot. This actually links to https://www.python.org/download/releases/3.4.1 WFM. I'm guessing this was a CDN caching problem--I forgot to manually purge the cache. Does it work for you now? //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.4.2 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.2. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the OS X installers are now distributed as signed installer package files compatible with the OS X Gatekeeper security feature. You can download it here: https://www.python.org/download/releases/3.4.2 May the road rise up to meet you, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Shrinky-dink Python (also, non-Unicode Python build is broken)
I'm an indie shareware Windows game developer. In indie shareware game development, download size is terribly important; conventional wisdom holds that--even today--your download should be 5MB or less. I'd like to use Python in my games. However, python24.dll is 1.86MB, and zips down to 877k. I can't afford to devote 1/6 of my download to just the scripting interpreter; I've got music, and textures, and my own crappy code to ship. Following a friend's suggestion, as an experiment I downloaded the Python 2.4.2 source, then set about stripping out everything I could. I removed: * Unicode support, including the CJK codecs * All doc strings * *Every* module written in C Now when I build, python24.dll is 570k, and zips down to about 260k. But I learned some things on the way. First and foremost: turning off Py_USING_UNICODE *breaks the build* on Windows. The following list of breakages were all fixed with judicious applications of #ifdef Py_USING_UNICODE: * The implementation of "multi-byte codecs" (CJK codecs) implicitly assumes that they can use all the Unicode facilities. So all the files in "Modules/cjkcodecs" fail to build. * Obviously, the Unicode string object depends on Unicode support, so Objects/unicode* doesn't build. * There are several spots in the code that need to handle Unicode strings in some slightly special way, and assume Unicode is turned on. E.g.: * Modules/posixmodule.c, posix__getfullpathname(), line 1745 * same file, posix_open(), starting on line 5201 * Objects/fileobject.c, open_the_file(), starting on line 158 * _winreg.c, Py2Reg(), starting on lines 724 and 777 In addition, there was one slightly more complicated problem: _winreg.c assumes it should call PyUnicode_DecodeMBCS() to turn strings pulled from the registry into Unicode strings. I'm not sure what the correct thing to do here is; I went with changing the calls from PyUnicode_DecodeMBCS() to PyString_FromStringAndSize() for non-Unicode builds. Of course, it's not the most important thing in the world--after all, I'm the first person to even *notice*, right? But it seems a shame that one can break the build so easily. If it pleases the stewards of Python, I would be happy to submit patches that fix the non-"using Unicode" build. Second of all, the dumb-as-a-bag-of-rocks Windows linker (at least the one used by VC++ under MSVS .Net 2003) *links in unused static symbols*. If I want to excise the code for a module, it is not sufficient to comment-out the relevant _inittab line in config.c. Nor does it help if I comment out the "extern" prototype for the init function. As far as I can tell, the only way to *really* get rid of a module, including all its static functions and static data, is to actually *remove all the code* (with comments, or #if, or whatnot). What a nosebleed, huh? So in order to build my *really* minimal python24.dll, I have to hack up the source something fierce. It would be pleasant if the Python source code provided an easy facility for turning off modules at compile-time. I would be happy to propose something / write a PEP / submit patches to do such a thing, if there is a chance that such a thing could make it into the official Python source. However, I realize that this has terribly limited appeal; that, and the fact that Python releases are infrequent, makes me think it's not a terrible hardship if I had to re-hack up each new Python release by hand. Whatcha think, froods? /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Shrinky-dink Python (also, non-Unicode Python build is broken)
There are exactly four non-Unicode build breakages in the Python source tree that are Win32-specific. Two are simply a matter of #if, two also require new alternative code (calls to PyString_FromStringAndSize()). All told, my changes to Win32-specific code to fix Py_USING_UNICODE consists of exactly twelve new lines of code. As for future development of Windows-specific Python features... doesn't that generally happen in modules, rather than the Python interpreter, these days? Either in Mark Hammond's pywin32 (what used to be called "win32all"), or perhaps done in Python using ctypes. There haven't been any changes to the three Windows-specific modules (msvcrt, winreg, and winsound) mentioned in any "What's New in Python 2.x" document, and 2.0 came out more than five years ago. /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Shrinky-dink Python (also, non-Unicode Python build is broken)
> Are you willing to monitor and fix new Py_USING_UNICODE issues or > are you proposing just to produce a patch now and then expect > contributors to maintain this feature? Neither, I suppose, or perhaps both. I am proposing to produce a patch now which fixes the non-Unicode build under Windows. However, I don't expect anything out of other contributors, and I don't set Python contribution policy. (Obviously the stewards of the Python tree don't care whether contributions break the non-Unicode build. But that's a fine policy; after all, they've already got enough to do, and in any case I'm the first person to even notice.) If this patch is accepted, and some future contribution breaks the non-Unicode build again, and I discover the breakage, I might very well create a second patch to re-fix it. Since I'm seemingly the only person who cares about non-Unicode builds on Windows, I suggest this approach would work just fine. /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32
I run the following script:
--
from subprocess import *
Popen("ls -l")
--
(yeah, I have ls.exe on Windows)
Under Python 2.4.2, this simply dumped the results of ls.exe to the
terminal--sorry, to the "command shell".
Under Python 2.5, both beta 1 and beta 2, it dumps the results to the
command shell, but *also* prints this:
Exception exceptions.AttributeError: "'NoneType' object has no
attribute 'append'" in > ignored
Calling Popen() with a stdout = subprocess.PIPE does not throw this
exception.
I vaguely intimate that this is a bug, though surely a minor one.
Cheers,
/larry/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32
Delaney, Timothy (Tim) wrote: > Could you raise this as a bug on Sourceforge? Done; it is "request ID" 1526203. https://sourceforge.net/tracker/index.php?func=detail&aid=1526203&group_id=5470&atid=105470 Cheers, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Nicko wrote: > I note that in both of those tests you didn't actually ever realise the > concatenated string. Can you give us figures for these tests having > forced the concatenated string to be computed? Sure, good call. And bad news. All these benchmarks were with functions taking N arguments that just added (concatenated) the arguments and returned the result. I only ran each benchmark once. | Python 2.5 | Python 2.5 arguments | release | concat -+--+-- 2 | 7718ms | 9078ms 3 | 9203ms | 10500ms 4 | 10656ms | 11656ms 5 | 12156ms | 13390ms 20 | 29359ms | 26703ms Interpret as you see fit, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
PATCH: Speed up direct string concatenation by 20+%!
This is such a long posting that I've broken it out into sections. Note that while developing this patch I discovered a Subtle Bug in CPython, which I have discussed in its own section below. THE OVERVIEW I don't remember where I picked it up, but I remember reading years ago that the simple, obvious Python approach for string concatenation: x = "a" + "b" is slow. Obviously it's fine for the simple case above, but if you're adding together twenty-five things: x = a + b + c + d + ... + y the performance is terrible, as the interpreter creates temporary objects for each intermediate result. (a + b, then (a + b) + c, then ((a + b) + c) + d, and so on.) The suggested idiom for fast string concatenation was this: x = "".join([a, b, c, d, ... y]) This works fine. But I don't like this approach, not only because it's kind of ugly and inobvious, but because it violates the "one obvious way to do it" principle. I mentioned all this to a friend of mine (Mike Thornburgh), and told him matter-of-factly that I'd like to fix this, but the design of Python simply precluded it. He said "no it doesn't!" and proceeded to describe in great detail an approach to permit fast string concatenation using +. I have implemented what he suggested--with only slight changes--and present it to you below. I only had to touch four files, and only did major surgery on one. The resulting Python passes the test suite as well as my unmodified locally-built Python 2.5. (I didn't install the external source trees for stuff like SQLite, so it fails those tests.) Note that times have changed; using Python 2.5, a + b + c isn't *that* much slower than "".join([]). But is is still slower. Or, was--with my patch, a + b + c becomes *the fastest method* for string concatenation. Hooray! (It didn't pay off as *much* as I'd hoped, but it's still an improvement.) _ THE PATCH The core concept: adding two strings together no longer returns a pure "string" object. Instead, it returns a "string concatenation" object which holds references to the two strings but does not actually concatenate them... yet. The strings are concatenated only when someone requests the string's value, at which point it allocates all the space it needs and renders the concatenated string all at once. More to the point, if you add multiple strings together (a + b + c), it *doesn't* compute the intermediate strings (a + b). Upsides to this approach: * String concatenation using + is now the fastest way to concatenate strings (that I know of). * Throw off the shackles of "".join([]), you don't need it anymore. * Did I mention it was faster? Downsides to this approach: * Changes how PyStringObjects are stored internally; ob_sval is no longer a char[1], but a char *. This makes each StringObject four bytes larger. * Adds another memory dereference in order to get the value of a string, which is a teensy-weensy slowdown. * Would force a recompile of all C modules that deal directly with string objects (which I imagine is most of them). * Also, *requires* that C modules use the PyString_AS_STRING() macro, rather than casting the object and grabbing ob_sval directly. (I was pleased to see that the Python source was very good about using this macro; if all Python C modules are this well-behaved, this point is happily moot.) * On a related note, the file Mac/Modules/MacOS.c implies that there are Mac-specific Python scripts that peer directly into string objects. These would have to be changed to understand the new semantics. * String concatenation objects are 36 bytes larger than string objects, and this space will often go unreclaimed after the string is rendered. * When rendered, string concatenation objects storing long strings will allocate a second buffer from the heap to store the string. So this adds some minor allocation overhead (though this is offset by the speed gain from the approach overall). * Will definitely need some heavy review before it could go in, in particular I worry I got the semantics surrounding "interned" strings wrong. Internally, a "string concatenation" object is the same as a "string" object with two extra fields: an array of references to string objects (and string concatenation objects), and a count. Also, ob_sstate now stores a third flag, indicating whether or not the string is a string concatenation object. External users don't need to worry about these details, they just use PyString_AS_STRING() and all is well with their world. I've already added some optimizations to the approach: * If you're adding a string to an existing string concatenation object whose reference
Re: PATCH: Speed up direct string concatenation by 20+%!
Steve Holden wrote:
> you should diff your source against the current
> SVN repository and lodge that diff as a patch on SourceForge.
Okay, I'll try to do that today.
> Your suggested bug isn't, I think a real bug in the current
> implementation because as I understand it Python strings do always
> include a trailing null byte to act as a terminator when the string
> is passed to C code in extensions.
Ah! Excellent point. So the Python source tree *does* have an
official position on what the first byte of a zero-length string should
be. I'll fix my code so that is ensured.
> Nice idea, though. You might also see how it does on tasks like
>
> s = ""
> for i in range(10):
> s += "a"
Sure. Here are the results, but with range (1000):
Python 2.5 release: 31.0s
Python 2.5 locally built: 30.7s
Python 2.5 concat: 4.4s
% Improvement: *697%*!
Woah! Thanks for suggesting a benchmark where it really shines :)
The real big win here is storing eight pointers per concatenation
object. That means 1/8th as many objects created/destroyed.
In testing your suggested benchmark, it overflowed the stack
when freeing the concatenation tree. So I changed deallocation
of string concatenation objects so it's iterative down the
left-hand side like rendering; now it's happy again. Thanks
again for suggesting the test.
It would still blow up if you ran
s = ""
for i in range(1000):
s = "a" + s
because it's only clever about recursion down the left-hand side.
So my advice is, don't. :)
> Also note that some optimisation has recently been performed on string
> concatenation, which I presume your code has already taken into account.
Totally. I'm just glad there was something left for me to contribute!
Rob Williscroft wrote:
> On the python 3k list there is a thread about stings becoming "views",
> I think this is similar to what you are doing here.
As I understand it, sort-of. Definitely moreso in my section on THE
FUTURE--adding another subtype of string for slices which point into
other strings. I believe views are more sophisticated however.
Felipe Almeida Lessa wrote:
> What about "a + b"? Or "a + b + c"? Does it have a large overhead on
> small string concatenations?
It's *slightly* slower for two:
def addTwoThings(a, b):
return a + b
for i in range(1000):
x = addTwoThings("aaa", "bbb")
Python 2.5 release: 6.219s
Python 2.5 locally built: 6.219s
Python 2.5 concat: 6.234s
% improvement: -0.03%
But starts paying off already, even with three:
def addThreeThings(a, b, c):
return a + b + c
for i in range(1000):
x = addThreeThings("aaa", "bbb", "ccc")
Python 2.5 release: 7.9s
Python 2.5 locally built: 7.7s
Python 2.5 concat: 7.2s
% improvement: 6.94%
Note that I was lazy and only did one benchmark run apiece.
Also, keep in mind that memory utilization will be a little higher
with the string concatenation objects.
Carl Friedrich Bolz wrote:
> Robin Becker wrote:
> > wouldn't this approach apply to other additions eg list+list seq+seq etc
> > etc.
> no, I think it depends on strings being immutable.
Exactly.
/larry/
--
http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Fredrik Lundh wrote: > > Sure. Here are the results, but with range (1000): > ten million? what hardware are you running this on? Athlon 64 x2 4400+ (aka 2.2GHz), 3GB of RAM, Windows XP. > what's in "s" when that loop is done? It's equivalent to " 'a' * 1000 ". (I shan't post it here.) Also, I misspoke earlier; it's not an improvement of 697%, but of 597%. To be precise, it takes about 1/7 the time of the original. Cheers, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
William Heymann wrote: > This is a pretty small change but I would suggest xrange instead of range. Good point! Since I was calling range() during the benchmark, it was timed too. Switching to xrange() will mean less overhead. I re-ran this benchmark (again): s = "" for i in range(10): s += "a" The result: Python 2.5 release: 30.1s Python 2.5 locally built: 30.4s Python 2.5 concat: 3.95s Improvement: *669%*! (1/7.7 the time.) So xrange(1000) was adding between 0.4s and 0.9s overhead, and losing it makes my approach look even better. Thanks! /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Fredrik Lundh wrote: > >> what's in "s" when that loop is done? > > It's equivalent to " 'a' * 1000 ". (I shan't post it here.) > but what *is* it ? an ordinary PyString object with a flattened buffer, > or something else ? At the exact moment that the loop is done, it's a PyStringConcatenationObject * which points to a deep one-sided tree of more PyStringConcatenationObject * objects. Its ob_sval is NULL, which means that the first time someone asks for its value (via the macro PyString_AS_STRING()) it will be computed. When it's computed, the interpreter will allocate a buffer of 1001 bytes and walk the tree, filling the buffer with ten million 'a's followed by a zero. It'll then dereference all its children. The PyStringConcatenationObject struct is a child of PyStringObject, and external users can ignore the difference as long as they use the macros in stringobject.h (e.g. using PyString_AS_STRING(), rather than casting to PyStringObject and using ob_sval directly). Sorry for misunderstanding the nature of your question the first time, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Fredrik Lundh wrote: > so what does the benchmark look like if you actually do this ? Okay, timing this: x = "" for i in range(10): x += "a" t = x[1] # forces the concat object to render The result: Python 2.5 release: 30.0s Python 2.5 locally built: 30.2s Python 2.5 concat: 4.3s Improvement: 600% (1/7 of the time) /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
An update: I have submitted this as a patch on SourceForge. It's request ID #1569040. http://sourceforge.net/tracker/?group_id=5470&atid=305470 I invite everyone to take it for a spin! There are some improvements in this version. Specifically: * Python will no longer crash if you do ten million prepends ( x = 'a' + x ). Since the problem was blowing the stack with an incredibly deep render, I now limit the depth of the string concatenation objects (currently set at 16384). Note that string prepending is now *immensely* faster, as prepending in the existing implementation is a worst-case. * I figured out why my zero-length strings were occasionally not zero terminated. It had to do with subclassing a string and storing an attribute in the object, which meant storing a dict, and where specifically the interpreter chose to store that. The solution was essentially to ensure there's always space in the object for the trailing zero. When running regrtest.py, my patched version produces identical output to a non-patched build on Windows. Steve Holden wrote: > Does a comparison also force it to render? Yes. Any attempt to examine the string causes it to render. > It does sound like memory usage > might go through the roof with this technique under certain > circumstances, so the more extensive your tests are the more likely you > are to see the change actually used (I'm not convinced you'll persuade > the developers to include this). Yeah, I expect memory usage to be higher too, but not by a fantastic amount. Once you render the concatenation, it drops all the references to the child objects held in the tree, and what's left is a string object with some extra space on the end. > I think your project might make a very > interesting PyCon paper for people who were thinking about joining the > development effort but hadn't yet started. Perhaps; I've never been to PyCon, but it might be fun to give a presentation there. That said, it would be way more relevant if the patch got accepted, don'tcha think? Cheers, /larry/ p.s. Thanks for the sentiment, Colin W.! -- http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Fredrik Lundh wrote:
> You should also benchmark this against code that uses the ordinary
> append/join pattern.
Sorry, thought I had. Of course, now that the patch is up on
Sourceforce you could download it and run all the benchmarks you like.
For all the benchmarks I ran below, the number listed is the best of
three runs. Time was computed using sum(os.times()[:2]).
Running this under Python 2.5 release:
x = []
for i in xrange(1000):
x.append("a")
y = "".join(x)
took 4421ms.
Running this under my patched Python:
x = ""
for i in xrange(1000):
x += "a"
y = x[1]
took 4406ms.
I assert that my code makes + as fast as the old "".join([]) idiom.
> It's rather unlikely that something like this will ever be added to
> the 2.X series. It's pretty unlikely for 3.X as well (GvR used a
> rope-like structure for ABC, and it was no fun for anyone), but it'll
> most likely be a lot easier to provide this as an option for 3.X.
I can't address the ABC implementation as I've never seen it. But my
patch only touches four files. Two are obviously stringobject.c and .h.
The other two files, ceval.c and codeobject.c, only got one-line
changes. My changes to PyStringObject are well-encapsulated; as long
as core / extension programmers continue to use PyString_AS_STRING() to
access the char * in a PyStringObject they will never notice the
difference.
John Machin wrote:
> try benchmarking this ... well "style" may not be the appropriate word
Running this under Python 2.5 release:
x = []
xappend = x.append
for i in xrange(1000):
xappend("a")
y = "".join(x)
took 3281ms.
Running this under my patched Python 2.5:
x = ""
xappend = x.__add__
for i in xrange(1000):
xappend("a")
y = "".join(x)
took 3343ms.
/larry/
--
http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
John Machin wrote:
> Don't you mean y = x[1] or something like that? y = "".join(x) looks
> like a copy-paste error.
You're right, by gum. Worse than that, my benchmark wasn't actually
*doing* much of anything there; at the end of the run x was still
length 0. That was sloppy, and I apologize.
I cannot find a speedy equivalent to the 'xappend = x.append' trick for
string concatenation using +. 'operator.__iadd__' is slower, a labored
attempt using 'x = x("a").__add__' is better but still slower. So far,
just calling 'x += "a"' is the fastest way, and that's 4.4s, still beat
by the 'xappend = x.append' trick at 3.2s.
> Playing the devil's advocate here: 10M adds each of a single byte
> followed by 1 render doesn't seem very typical. How about [...]
> Some of us have Windows boxes and don't have the necessary MS compiler.
> Is there any chance of someone making a 2.5+patch Windows binary?
I actually developed it on Windows. Here you go:
http://larryhastings.com/programming/lch.python.2.5.concat.zip
That contains the new python25.dll and my hacked-up benchmark script.
Just back up your existing python25.dll, then unzip to your Python
directory, and you're ready to rock.
Enjoy,
/larry/
--
http://mail.python.org/mailman/listinfo/python-list
Re: PATCH: Speed up direct string concatenation by 20+%!
Istvan Albert wrote: > I remember a similar patch from some time ago: > > http://mail.python.org/pipermail/python-dev/2004-August/046686.html That patch addressed the same general problem, but took a completely different approach. For the record, this patch (#980695) optimized "x += a" by examining the next instruction after the addition. If it's a store instruction, and the object being stored to holds a reference to the left side of the concatenation, it makes the object drop the reference *before* doing the concatenation. In the case where there was only one reference to the string on the left side (that being "x"), this allows the string concatenation function to use a very fast shortcut: resize the left side and concatenate the right side directly to the end. The patch was accepted in August of 2004, so it might have been folded in to CPython during the 2.3 era; certainly it was part of CPython 2.4. And, happily, that optimization is complimentary to mine. In my patch, when the left side only has one reference and it's a "string concatenation object", it will often have space left in its internal array of strings objects. In that case I just append the string. Speeds things up immensely. Cheers, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
How to use Mercurial for local source code management with a public Subversion server
I'm working on a patch or two for Python. Now, it's always best to use a source code manager (rcs, whatever) when writing code; in particular it'd make updating to the latest Python trees much easier. But I don't have write access to the Python Subversion repository. So I figured out how to work purely locally with Mercurial. I wrote a long(ish) how-to blog entry about it, . It's currently the top entry, here: http://www.momentaryfascinations.com/ Figuring out *how* to do it was the hard part; it's actually pretty easy to set up and use. And *very* pleasant to work with! If you're working on patches for Python, I highly recommend you work using something like this. (Maybe even if you *do* have write permission!) I considered posting this in the Python-Dev mailing list, as that's really the target audience, but I wasn't sure the message would be happily received by its subscribers. Cheers, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Would you support adding UNC support to os.path on Windows?
I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows. You can read about it at the Python bug tracker: http://bugs.python.org/issue5799 I'd like to gauge community interest in the patch. After all, it's has been declined before; I submitted a similar patch for 1.5.2 way back in 1999. (You can read the details of that on the tracker page too.) So: would you like to see this patch committed? Your votes, ladies and gentlemen, if you please. For what it's worth, Mark Hammond supports this patch. (But then, iirc he supported it 1999 too.) /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Cleaning out the cobwebs in the PEP cupboard
There are some PEPs that seem to be stuck in a perpetual limbo, never to be decided upon. Some of them seem hopelessly antiquated now--they were proposed long ago and the language has moved on. With every passing day it becomes less likely they will ever be Accepted. On the off chance that their fate is decided and we just hadn't noticed, I thought I'd take a couple of minutes, talk about some of those PEPs, and make some suggestions. I fear I am jamming multiple feet into my mouth; honest, I mean no harm. Just trying to get the wheels of fate turning once again. We start with one I think is terribly obvious. PEP 333: Python Web Server Gateway Interface v1.0 http://www.python.org/dev/peps/pep-0333/ The WSGI PEP. Even though it's six years old, and mighty empires have been built upon its rock-solid foundations, it's still marked as "Draft". This is sillier than Gmail still being marked "beta". In the name of Guido's shiny time machine: could PEP 333 please be formally Accepted? The rest of these are marked "deferred", and date from very early in the decade, sometimes even before Python 2.0. PEP 211: Adding A New Outer Product Operator http://www.python.org/dev/peps/pep-0211/ This proposes @ as a "product" operator for iteration. It would make "for i, j in S @ T:" equivalent to "for i in S: for j in T:". Since then we've added generator expressions and itertools. In particular, itertools.product (added in 2.3) solves exactly the problem described, and as it's in C it wouldn't be any faster if this were an operator. The only debate left is whether this is important enough to warrant the shorter spelling. If brevity is that important, do "from itertools import product as p". That would add a net of two extra characters per iteration. I therefore gently suggest that this PEP be Rejected (or Withdrawn). PEP 212: Loop counter iteration http://www.python.org/dev/peps/pep-0212/ This PEP attempts to solve two problems: "for i in range(len(x)): e = x[i]" is inconvenient and wordy, and "for i in range(len(x)):" is wordy. It proposes either a new keyword (indexing), two global functions (irange and indices respectively for the two problems), and/or two method calls on sequences mirroring the proposed global functions. The former problem was addressed with enumerate (added in 2.3, see PEP 279). The latter problem is not severe or common enough to really need addressing. Certainly it doesn't merit a keyword or a new method on every iterable; I don't think it even merits a global function. The right place for this function, if we want it at all, would be in itertools. I therefore gently suggest that this PEP also be Rejected (or Withdrawn). PEP 213: Attribute Access Handlers http://www.python.org/dev/peps/pep-0213/ This proposes an extension to classes to allow overriding access to members on a case-by-case basis. Instead of writing one big __getattr__, you could write individual methods called __attr_XXX__ to override behavior on self.XXX. In other words: properties. This was years before Python 2.2 and the mighty PEP 252 which introduced properties. Properties solves this exact problem. This PEP actually discusses 252 at the end, staring its own fate in the eye. While I admire its courage, there is no chance of this PEP being Accepted. Once again I must recommend Rejection (or Withdrawl). PEP 222: Web Library Enhancements http://www.python.org/dev/peps/pep-0222/ This is an open-ended "we should make Python library support for CGI better" proposal. It is not terribly specific; it seems to have been proposed in a deferred state. Back before 2.1. Since then, CGI has fallen by the wayside; no serious server-side developer would willingly incur a new process per request. We also have the aforementioned WSGI, which addresses the only specific area of the proposal (the Request and Response objects). In any case I suggest that this is not the proper way to approach this topic. Instead, someone / some folks should /write/ such a module, release it on the 'net, get lots of happy users, and /then/ propose submitting it to the standard library. Therefore this PEP should be Rejected (or Withdrawn). PEP 225: Elementwise/Objectwise Operators http://www.python.org/dev/peps/pep-0225/ This proposes six new binary operators: ~+ ~- ~* ~/ ~% and ~**, and six new augmented assignment operators (add = to the end of the previous six). These would be used for numeric expressions to differentiate between elementwise operations (operate on individual elements of the two operands) and objectwise operations (operate on each of the two operands as a whole). My math isn't good enough to say how necessary this is. But it's been more than eight years since it was proposed; if it was that necessary su
Re: Would you support adding UNC support to os.path on Windows?
norseman wrote: "...This patch changes "ntpath" ..."changing or adding to such a module which is OS specific is fine with me. [...] To point it bluntly: How does one use "F:" in Linux in the identical fashion as a MicroSoft OS? Sorry, I assumed this was common knowledge: os.path is implemented by different modules depending on what operating system you're using. On Windows it uses "ntpath", on OS2 it may use "os2emxpath" or "ntpath" depending, and on all other platforms it uses "posixpath". My patch adds UNC path support to "ntpath"; it does not modify the other "path" implementations. And sorry for the late reply, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
Best practices for simultaneously installed versioned packages?
I'm writing a package for Python 3--let's call it "spacegoblin". I fear someday I may need multiple versions installed and available simultaneously, even within one version of Python. So I want to plan ahead for that possibility. What would be the best way to allow this? Right now I install the package with the version in the name, like "spacegoblin_1_0" and "spacegoblin_1_1". But I have an uneasy sense that I'm doing something stupid... mainly because I've never seen anyone do this before. A coworker said they did it like "spacegoblin.1_0" and "spacegoblin.1_1" at a previous employer. That seems like an improvement, though not the "yes that's obviously right" answer I'm holding out for. Your thoughts? Thanks, /larry/ p.s. Before you ask: no, I don't want to use "virtualenv" for this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best practices for simultaneously installed versioned packages?
In article , Benjamin Kaplan wrote: wxpython installs a "wxversion" module which has functions like getInstalled(), ensureMinimal(version), and select(version). You can call wxversion.select before importing wx and it will make sure that the correct version is imported. You might want to look up what they did. I can imagine what they did: wxversion.select() explicitly imports the desired wxwindows module using __import__(), then assigns it to sys.modules["wxwindows"]. A good idea! Ned Deily wrote: Also, setuptools (and, its successor, distribute, which supports Python 3) allow the installation and management of multiple versions of a package within one python site-library instance. That sounds lovely too, but I can't figure out what facility setuptools / distribute permits that. Could you be more specific? A link to the documentation for this feature would be much appreciated. Thanks, /larry/ -- http://mail.python.org/mailman/listinfo/python-list
RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm relieved to announce the availability of Python 3.4.7rc1 and Python 3.5.4rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5.4 will be the final 3.5 release in "bug fix" mode. After 3.5.4 is released, Python 3.5 will also move into "security fixes mode". Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.7rc1 here: https://www.python.org/downloads/release/python-347rc1/ And you can find Python 3.5.4rc1 here: https://www.python.org/downloads/release/python-354rc1/ Python 3.4.7 final and Python 3.5.4 final are both scheduled for release on August 6th, 2017. Happy Pythoning, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.4 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.4. Python 3.5.4 is the final 3.5 release in "bug fix" mode. The Python 3.5 branch has now transitioned into "security fixes mode"; all future improvements in the 3.5 branch will be security fixes only, and no conventional bug fixes will be merged. You can find Python 3.5.4 here: https://www.python.org/downloads/release/python-354/ Python 3.4.7 final will be released later today. Happy Pythoning, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.7 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.7. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. You can find Python 3.4.7 here: https://www.python.org/downloads/release/python-347/ Happy Pythoning, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
