Just a small note, MD5 for RC2 file python-3.3.0rc2.msi is not correct on http://python.org/download/releases/3.3.0/
it would be nice if someone can update it
On Sunday, September 9, 2012 4:25:39 AM UTC-5, Georg Brandl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On behalf of the Python development team, I'm delighted to announce the
> second release candidate of Python 3.3.0.
> This is a preview release, and its use is not recommended in
> production settings.
> Python 3.3 includes a range of improvements of the 3.x series, as well
> as easier porting between 2.x and 3.x. Major new features and changes
> in the 3.3 release series are:
> * PEP 380, syntax for delegating to a subgenerator ("yield from")
> * PEP 393, flexible string representation (doing away with the
> distinction between "wide" and "narrow" Unicode builds)
> * A C implementation of the "decimal" module, with up to 80x speedup
> for decimal-heavy applications
> * The import system (__import__) now based on importlib by default
> * The new "lzma" module with LZMA/XZ support
> * PEP 397, a Python launcher for Windows
> * PEP 405, virtual environment support in core
> * PEP 420, namespace package support
> * PEP 3151, reworking the OS and IO exception hierarchy
> * PEP 3155, qualified name for classes and functions
> * PEP 409, suppressing exception context
> * PEP 414, explicit Unicode literals to help with porting
> * PEP 418, extended platform-independent clocks in the "time" module
> * PEP 412, a new key-sharing dictionary implementation that
> significantly saves memory for object-oriented code
> * PEP 362, the function-signature object
> * The new "faulthandler" module that helps diagnosing crashes
> * The new "unittest.mock" module
> * The new "ipaddress" module
> * The "sys.implementation" attribute
> * A policy framework for the email package, with a provisional (see
> PEP 411) policy that adds much improved unicode support for email
> header parsing
> * A "collections.ChainMap" class for linking mappings to a single unit
> * Wrappers for many more POSIX functions in the "os" and "signal"
> modules, as well as other useful functions such as "sendfile()"
> * Hash randomization, introduced in earlier bugfix releases, is now
> switched on by default
> In total, almost 500 API items are new or improved in Python 3.3.
> For a more extensive list of changes in 3.3.0, see
> To download Python 3.3.0 visit:
> Please consider trying Python 3.3.0 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.3's contributors)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> -----END PGP SIGNATURE-----
% cd ~ && svn co http://svn.snakebite.net/.snakebite && cd .snakebite && sh snakebite.subr
If all goes well, you should see something like this:
Checked out revision 58.
Created link for 'sb'.
Created link for 'sbx'.
Created link for 'sby'.
Created link for 'sbctl'.
Fixed permissions for /Users/Trent/.snakebite/snakebite.subr.
The following commands can now be executed directly:
Getting a list of your projects...done.
Looking up your username for project 'cpython'...done.
Getting project details for 'trent.nelson@cpython'...done.
Setting current project to 'cpython'...done.
Trent, you're now configured for cpython. Enjoy!
| Available Hosts |
| (Last Update: 2012-09-11 11:08:01Z) |
| Alias | OS | Arch |
| a7|AIX 7.1 | Power4 |
| d3|DragonFlyBSD 3.0.2 | x64 |
| d3x|DragonFlyBSD 3.0.2 | x86 |
| h2|HP-UX 11iv2 | PA-RISC |
| h3|HP-UX 11iv3 | Itanium2 |
| i6|IRIX 6.5.30 | MIPS |
| n51|NetBSD 5.1.2 | x64 |
| n51x|NetBSD 5.1.2 | x86 |
| o51x|OpenBSD 5.1 | x86 |
| o51|OpenBSD 5.1 | x64 |
| s10|Solaris 10 | SPARC |
| s9|Solaris 9 | SPARC |
Simply enter any of the aliases in the table and it'll ssh you into
that box as cpython@, i.e.:
Enter alias: a7
AIX arsenic 1 7 000BF95F4C00
:::. :::::::.. .::::::. .,:::::: :::. :::. ::: .,-:::::
;;`;; ;;;;``;;;; ;;;` ` ;;;;'''' `;;;;, `;;; ;;; ,;;;'````'
,[[ '[[, [[[,/[[[' '[==/[[[[, [[cccc [[[[[. '[[ [[[ [[[
c$$$cc$$$c $$$$$$c ''' $ $$"""" $$$ "Y$c$$ $$$ $$$
888 888, 888b "88bo, 88b dP 888oo,__ 888 Y88 888 `88bo,__,o,
YMM ""` MMMM "W" "YMmMY" """"YUMMM MMM YM MMM "YUMMMMMP"
IBM IntelliStation 9114-275
2 x 1.4GHz Power4 CPUs
2 x 2Gbps LP9802 FC HBAs
8GB RAM, 4 x 36GB
- Almost all of the hosts have a corresponding cpython build slave,
which always lives in ~/buildslave.
- You're more than welcome to set up local builds on each box.
Keep everything in ~/hg. Some hosts already have a ~/hg dir,
others don't. The layout should be:
If they don't exist, feel free to create them. It's going to
be easiest to just clone the corresponding build directory
from ~/buildslave, i.e. if you want a local 3.x area but no
% cd ~/hg
% hg clone ~/buildslave/3.x-*/build 3.x
Once a base repo has been created, you can clone a local copy:
hg clone 3.x 3.x.trent.issue2811
Try follow that naming convention as it'll make it easier for
other developers to figure out what each directory is for.
Also, try and keep tabs on local builds and remove things you
don't need once you're done. I haven't finished hooking up
the SAN yet so everything is on local disks at the moment;
disk space is a bit light in some places.
- If you're not used to vi shell key bindings, you're going to
have a bad time :-)
- Almost all of the hosts (except for the *BSDs) have been set
up to use a common ~/.zsh and ~/.vim:
They're both based on random dotfile hacking I've done over
the years and are far from elegant -- so, suggestions welcome.
If I'm awake and working, I'll be on #python-dev, so that'll be the
best place to get me if you need immediate assistance.
So, log in and have a play around! Oh, X11 forwarding works, too,
just invoke `sbx` (or `sby`) instead of `sb` and it'll invoke ssh
with -X or -Y respectively. All the proprietary UNIX hosts have
X11 installed, complete with glorious circa-late-nineties Motif
For those looking for tangible things to do... take a look at the
current buildslaves with [SB] in the name -- almost all of them are
failing in some way/shape/form, so there's plenty of stuff to get
your teeth stuck into :-)
(I apologize for posting HTML mail. Retrying.)
Hi. I am implementing complex numbers for pypy's version of numpy.
Numpy has both 128 bit (based on 64 bit floats) and 64 bit (based on 32
bit floats) complex numbers, where afaict cmath uses strictly 128 bit
complex numbers. I made sure the 128 bit numpy complex numbers in pypy
pass the tests in Lib/tests/cmath_testcases.txt.
I would like to generate a similar file to cmath_testcases.txt for 64
bit complex numbers. I found the earliest commit of the file at
Can the authors of the original file help me reconstruct the scripts or
programs used to generate it, and reformulate them for 32 bit floats?
Since there are more than 2000 cases, and many need rewriting, I prefer
an automated method to error-prone hand coding.
By the way, the level of testing is most impressive.
Thanks for any help or tips,
Did you mean to use http://docs.python.org/devguide/developers.html instead
of http://hg.python.org/committers.txt as the former lists why while the
latter just lists usernames?
On Sun, Sep 9, 2012 at 3:19 AM, georg.brandl <python-checkins(a)python.org>wrote:
> changeset: 548:b40bfc99c54f
> user: Georg Brandl <georg(a)python.org>
> date: Sun Sep 09 09:20:23 2012 +0200
> Update committers list location.
> coredev.rst | 4 ++--
> faq.rst | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
> diff --git a/coredev.rst b/coredev.rst
> --- a/coredev.rst
> +++ b/coredev.rst
> @@ -25,7 +25,7 @@
> able to commit them without supervision.
> A complete list of core developer usernames can be found at
> -http://www.python.org/dev/committers. :ref:`developers` lists when and
> +http://hg.python.org/committers.txt. :ref:`developers` lists when and why
> someone received commit privileges.
> @@ -68,7 +68,7 @@
> This should match your username on the issue tracker.
> You can verify your commit access by looking at
> -http://www.python.org/dev/committers which lists all core developers by
> +http://hg.python.org/committers.txt which lists all core developers by
> username. If you want to practice, there is a `test repository
> <http://hg.python.org/test/>`_ where you can freely commit and push any
> changes you like::
> diff --git a/faq.rst b/faq.rst
> --- a/faq.rst
> +++ b/faq.rst
> @@ -96,7 +96,7 @@
> On the `issue tracker`_, most core developers will have the Python logo
> appear next to their name.
> -.. _full list of developers: http://www.python.org/dev/committers
> +.. _full list of developers: http://hg.python.org/committers.txt
> What standards of behaviour are expected in these communication channels?
> Repository URL: http://hg.python.org/devguide
> Python-checkins mailing list
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm delighted to announce the
second release candidate of Python 3.3.0.
This is a preview release, and its use is not recommended in
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
To download Python 3.3.0 visit:
Please consider trying Python 3.3.0 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.3's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
On Sun, 9 Sep 2012 09:11:08 +0200 (CEST)
georg.brandl <python-checkins(a)python.org> wrote:
> diff --git a/developers.rst b/developers.rst
> --- a/developers.rst
> +++ b/developers.rst
> @@ -26,9 +26,12 @@
> - Daniel Holth was given push privileges on Sep 9 2012 by GFB, for PEP editing.
> -- Peter Moody was given push privileges on May 20 2012 by Antoine Pitrou
> - for authorship and maintenance of the ipaddress module (accepted in PEP
> - 3144 by Nick Coghlan).
> +- Eric Snow was given push privileges on Sep 5 2012 by Antoine Pitrou for
> + general contributions, on recommendation by Nick Coghlan.
Oops, sorry, I had forgotten to update the developers list.
Software development and contracting: http://pro.pitrou.net
On hg.python.org, it seems like the entries on the "log" page don't
always link to the corresponding revision:
This seems to happen whenever the revision description begins with
text that results in a link to something else (e.g. an issue number),
"Issue #15822: Fix installation of lib2to3 grammar pickles to ensure."
In contrast, the "graph" page seems always to link to the revision:
Related to this, if the description field contains text that results
in a link to something else, then the UI doesn't make a distinction
between the portion of the description that links to the revision and
the portion that links to the something else.
For example, with description text "Fix for fcc629208842", "Fix for"
links to the revision for the log entry, but "fcc629208842" links to
the named revision, and there is no separation or visual indicator
that the two portions of text link to different things.
It might be better if the revision link was separate from the
description text. That would be one way to address both of the issues