[RELEASED] Python 3.2
Georg Brandl
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:
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 :)
Stefan Behnel
> On behalf of the Python development team, I'm delighted to announce
> Python 3.2 final release.
> Please consider trying Python 3.2 with your code and reporting any bugs
> you may notice to:
>
> http://bugs.python.org/
Note to packagers: This release has a critical bug in distutils that
prevents .pyc files from being byte compiled to their proper location
during installation, thus preventing them from being used.
http://bugs.python.org/issue11254
Stefan
Duncan Booth
> Please consider trying Python 3.2 with your code and reporting any bugs
> you may notice to:
>
> http://bugs.python.org/
>
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
--
Duncan Booth http://kupuguy.blogspot.com
Rafe Kettler
wrote:
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
> On Feb 21, 10:54 am, Duncan Booth wrote:
>> Georg Brandl<ge...@python.org> wrote:
>>> Please consider trying Python 3.2 with your code and reporting any bugs
>>> you may notice to:
>>
>>> http://bugs.python.org/
>>
>> 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
>
> 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
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
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
Irmen de Jong <irmen@-NOSPAM-xs4all.nl> wrote:
> 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/
--
Ned Deily,
n...@acm.org
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
Ned Deily <n...@acm.org> wrote:
> In article <4d640175$0$81482$e4fe...@news.xs4all.nl>,
> Irmen de Jong <irmen@-NOSPAM-xs4all.nl> wrote:
> > 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
>
> 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
--
Ned Deily,
n...@acm.org