I benchmarked some of the bigmemtests when run with -M 80G. They run really
slow, because they try to use all available memory, and then take a lot of
time processing it. Here are some runtimes:
test_capitalize (test.test_bigmem.StrTest) ... ok (420.490846s)
test_center (test.test_bigmem.StrTest) ... ok (149.431523s)
test_compare (test.test_bigmem.StrTest) ... ok (200.181986s)
test_concat (test.test_bigmem.StrTest) ... ok (154.282903s)
test_contains (test.test_bigmem.StrTest) ... ok (173.960073s)
test_count (test.test_bigmem.StrTest) ... ok (186.799731s)
test_encode (test.test_bigmem.StrTest) ... ok (53.752823s)
test_encode_ascii (test.test_bigmem.StrTest) ... ok (8.421414s)
test_encode_raw_unicode_escape (test.test_bigmem.StrTest) ... ok (3.752774s)
test_encode_utf32 (test.test_bigmem.StrTest) ... ok (9.732829s)
test_encode_utf7 (test.test_bigmem.StrTest) ... ok (4.998805s)
test_endswith (test.test_bigmem.StrTest) ... ok (208.022452s)
test_expandtabs (test.test_bigmem.StrTest) ... ok (614.490436s)
test_find (test.test_bigmem.StrTest) ... ok (230.722848s)
test_format (test.test_bigmem.StrTest) ... ok (407.471929s)
test_hash (test.test_bigmem.StrTest) ... ok (325.906271s)
In the test suite, we have the bigmemtest and precisionbigmemtest
decorators. I think bigmemtest cases should all be changed to
precisionbigmemtest, giving sizes of just above 2**31. With that
change, the runtime for test_capitalize would go down to 42s.
What do you think?
On Tue, 06 Sep 2011 01:53:32 +0200
victor.stinner <python-checkins(a)python.org> wrote:
> changeset: 72297:b1e03d10391e
> user: Victor Stinner <victor.stinner(a)haypocalc.com>
> date: Tue Sep 06 01:53:03 2011 +0200
> Issue #12567: Add curses.unget_wch() function
> Push a character so the next get_wch() will return it.
Looks like you broke many buildbots.
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm happy to announce the
Python 3.2.2 maintenance release.
Python 3.2.2 mainly fixes `a regression <http://bugs.python.org/12576>`_ in the
``urllib.request`` module that prevented opening many HTTP resources correctly
with Python 3.2.1.
Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line. Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.
Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3. Highlights are:
* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations
For a more extensive list of changes in 3.2, see
To download Python 3.2 visit:
Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----
pretty much a year ago I wrote about the optimizations I did for my
PhD thesis that target the Python 3 series interpreters. While I got
some replies, the discussion never really picked up and no final
explicit conclusion was reached. AFAICT, because of the following two
factors, my optimizations were not that interesting for inclusion with
the distribution at that time:
a) Unladden Swallow was targeting Python 3, too.
b) My prototype did not pass the regression tests.
As of November 2010 (IIRC), Google is not supporting work on US
anymore, and the project is stalled. (If I am wrong and there is still
activity and any plans with the corresponding PEP, please let me
know.) Which is why I recently spent some time fixing issues so that I
can run the regression tests. There is still some work to be done, but
by and large it should be possible to complete all regression tests in
reasonable time (with the actual infrastructure in place, enabling
optimizations later on is not a problem at all, too.)
So, the two big issues aside, is there any interest in incorporating
these optimizations in Python 3?
Have a nice day,
PS: It probably is unusual, but in a part of my home page I have
created a link to indicate interest (makes both counting and voting
easier, http://www.ics.uci.edu/~sbruntha/) There were also links
indicating interest in funding the work; I have disabled these, so as
not to upset anybody or make the impression of begging for money...