[RELEASED] Python 3.2

[Georg Brandl]

On behalf of the Python development team, I'm delighted to announce
Python 3.2 final release.

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
hostname matching
* 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

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

 

[Peter Otten]

On behalf of the Python development team, I'm delighted to announce
Python 3.2 final release.

Congratulations for your first as release manager, and a big thank you to
you and all who contributed to this realease.

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
hostname matching
* 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

This is an impressive list. It looks like Python 3 is now ready for mass
adoption

 

[Rafe Kettler]

It looks like this release breaks the builtin `input()` function on Windows
by leaving a trailing '\r' on the end of the string.

Reported as issue 11272:http://bugs.python.org/issue11272

Are fixes for these bugs going to wait until the next release (3.2.1 I
guess) or will update as soon as the fixes are available? I want to
know if I should be on the lookout for a better version of 3.2.

Rafe

 

[Stefan Behnel]

Rafe Kettler, 21.02.2011 17:30:

Are fixes for these bugs going to wait until the next release (3.2.1 I
guess)

Yes. That's what "the next release" means.

or will update as soon as the fixes are available?

You mean: as soon as someone writes a fix?

I want to know if I should be on the lookout for a better version of 3.2.

Better test now and report any problems you find. (Actually, that's what
the beta/RC phase was there for, but it's never too late to find a bug.)

Stefan

 

[Irmen de Jong]

On behalf of the Python development team, I'm delighted to announce
Python 3.2 final release.

Thanks to all the people who worked on this.

However, I'm having trouble compiling a framework build from source on
Mac OS 10.5.8 on PowerPC. No matter what I try (gcc 4.0, gcc 4.2,
different compiler options), the compilation aborts with the following
error:

Undefined symbols:
"___fixdfdi", referenced from:
_rlock_acquire in libpython3.2m.a(_threadmodule.o)
_lock_PyThread_acquire_lock in libpython3.2m.a(_threadmodule.o)
"___moddi3", referenced from:
_PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
_acquire_timed in libpython3.2m.a(_threadmodule.o)
"___divdi3", referenced from:
_PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
_acquire_timed in libpython3.2m.a(_threadmodule.o)
ld: symbol(s) not found
/usr/bin/libtool: internal link edit command failed

Google isn't much help; I tried linking with -lgcc, forcing the
processor architecture to G4, but nothing seems to work ...

Can anyone shed some light on what the compilation flags were that are
used to build python.org's official i386+ppc universal build installer?
Or what other thing I might do wrong?

(Note: I have no trouble compiling a --enable-framework build on Mac OS
10.6.6 on intel. Also, a non-framework build compiles ok on the PPC mac.)

Thanks in advance.

Irmen de Jong.

 

[Benjamin Kaplan]

Thanks to all the people who worked on this.

However, I'm having trouble compiling a framework build from source on Mac
OS 10.5.8 on PowerPC.  No matter what I try (gcc 4.0, gcc 4.2, different
compiler options), the compilation aborts with the following error:

Undefined symbols:
 "___fixdfdi", referenced from:
     _rlock_acquire in libpython3.2m.a(_threadmodule.o)
     _lock_PyThread_acquire_lock in libpython3.2m.a(_threadmodule.o)
 "___moddi3", referenced from:
     _PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
     _acquire_timed in libpython3.2m.a(_threadmodule.o)
 "___divdi3", referenced from:
     _PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
     _acquire_timed in libpython3.2m.a(_threadmodule.o)
ld: symbol(s) not found
/usr/bin/libtool: internal link edit command failed

Google isn't much help; I tried linking with -lgcc, forcing the processor
architecture to G4, but nothing seems to work ...

Can anyone shed some light on what the compilation flags were that are used
to build python.org's official i386+ppc universal build installer?
Or what other thing I might do wrong?

(Note: I have no trouble compiling a --enable-framework build on Mac OS
10.6.6 on intel.  Also, a non-framework build compiles ok on the PPC mac.)

Thanks in advance.

Irmen de Jong.

Have you tried compiling it with Macports? The port file is too much
of a mess for me to figure out exactly what is getting called in what
circumstances, but whatever they're doing probably works.

 

[Irmen de Jong]

Have you tried compiling it with Macports? The port file is too much
of a mess for me to figure out exactly what is getting called in what
circumstances, but whatever they're doing probably works.

I have not, and I don't intend to. I figure Python.org's build is not a
macports one, and that it would be enough to have installed the Apple
developer tools (Xcode + toolchain) and use that to build straight from
the tarball. Have been doing that for ages, actually. I don't think I
tried compiling a --enable-framework build before though, because that
seems to be the only thing that's failing now.

Btw: just tried to compile Python 2.7.1 with --enable-framework, it
compiled without error on the powerpc mac.


regards

Irmen de Jong

 

[Benjamin Kaplan]

I have not, and I don't intend to. I figure Python.org's build is not a
macports one, and that it would be enough to have installed the Apple
developer tools (Xcode + toolchain) and use that to build straight from the
tarball. Have been doing that for ages, actually. I don't think I tried
compiling a --enable-framework build before though, because that seems to be
the only thing that's failing now.

Btw: just tried to compile Python 2.7.1 with --enable-framework, it compiled
without error on the powerpc mac.


regards

Irmen de Jong
--

There really isn't a "Macports build". Macports just downloads the
source tarball and compiles it locally. It's only doing three things
compared to compiling it yourself: update checking, dependency
tracking, and applying some patches for problems that haven't been
addressed upstream yet. One of the patches they have for Python 3.2
fixes something in the Makefile and it appears to have something to do
with the stuff being passed to libtool. Not sure if it's addresses
your problem or not, but it couldn't hurt to try it.
..
http://trac.macports.org/browser/trunk/dports/lang/python32/files/patch-Makefile.pre.in.diff

 

[Irmen de Jong]

There really isn't a "Macports build". Macports just downloads the
source tarball and compiles it locally. It's only doing three things
compared to compiling it yourself: update checking, dependency
tracking, and applying some patches for problems that haven't been
addressed upstream yet.

Ah, I'm sorry for my complete misunderstanding of what macports is then
I was under the impression that it was something like Cygwin for
Windows; a collection of tools and libraries ported to Mac OS and being
a distinct 'environment'.

One of the patches they have for Python 3.2
fixes something in the Makefile and it appears to have something to do
with the stuff being passed to libtool. Not sure if it's addresses
your problem or not, but it couldn't hurt to try it.
.
http://trac.macports.org/browser/trunk/dports/lang/python32/files/patch-Makefile.pre.in.diff

Thanks for the pointer Benjamin. Unfortunately, applying this patch
didn't make it fly. Gonna have to look further

Regards.
Irmen de Jong.

 

[Ned Deily]

However, I'm having trouble compiling a framework build from source on
Mac OS 10.5.8 on PowerPC. No matter what I try (gcc 4.0, gcc 4.2,
different compiler options), the compilation aborts with the following
error:

Undefined symbols:
"___fixdfdi", referenced from:
_rlock_acquire in libpython3.2m.a(_threadmodule.o)
_lock_PyThread_acquire_lock in libpython3.2m.a(_threadmodule.o)
"___moddi3", referenced from:
_PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
_acquire_timed in libpython3.2m.a(_threadmodule.o)
"___divdi3", referenced from:
_PyThread_acquire_lock_timed in libpython3.2m.a(thread.o)
_acquire_timed in libpython3.2m.a(_threadmodule.o)
ld: symbol(s) not found
/usr/bin/libtool: internal link edit command failed

Unfortunately, this is a variation of an old issue that hasn't yet been
fixed (http://bugs.python.org/issue1099). The simplest workaround is to
include the --enable-universalsdk option to configure, so something like
this:

../configure --enable-framework --enable-universalsdk=/

That has the side effect of causing a universal build (ppc and i386).
If you don't want to have that, you could go in an manually edit
Makefile.pre.in and eliminate the "test" and else clause starting at
line 487, in other words, always use gcc to make the framework library
and not libtool, and then rerun configure. I'll make sure the issue
gets resolved.

Another solution is to use the 3.2 32-bit installer for Mac OS X from
python.org:
http://www.python.org/download/releases/3.2/

 

[Irmen de Jong]

Unfortunately, this is a variation of an old issue that hasn't yet been
fixed (http://bugs.python.org/issue1099). The simplest workaround is to
include the --enable-universalsdk option to configure, so something like
this:

./configure --enable-framework --enable-universalsdk=/

Thank you Ned! That did the trick.
I'm not entirely sure what that option does (it seemed to fail when not
specifying it as '/', and '/' seems an odd location to set it to if it's
meant to be a filesystem path), but hey, the compilation succeeded.

Another solution is to use the 3.2 32-bit installer for Mac OS X from
python.org:
http://www.python.org/download/releases/3.2/

Yep, maybe I should have. I just like to tinker around too much myself I
suppose

Thanks again.
Irmen de Jong

 

[Ned Deily]

Unfortunately, this is a variation of an old issue that hasn't yet been
fixed (http://bugs.python.org/issue1099).

UPDATE: this problem has been fixed in the newly-release Python 3.2.1.
On a 10.4 or 10.5 PPC machine, you should now be able to successfully
build a PPC-only 3.2 framework with just:

../configure --enable-framework ; make

On 10.5, you may want to use:

../configure --enable-framework MACOSX_DEPLOYMENT_TARGET=10.5 ; make