-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm happy to announce the
second beta release of Python 3.3.0 -- a little later than originally
scheduled, but much better for it.
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:
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
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, Aug 12, 2012 at 1:25 AM, sandro.tosi <python-checkins(a)python.org> wrote:
> changeset: 78512:233673503217
> user: Sandro Tosi <sandro.tosi(a)gmail.com>
> date: Sun Aug 12 10:24:50 2012 +0200
> zip() returns an iterator, make a list() of it; thanks to Martin from docs@
> diff --git a/Doc/tutorial/datastructures.rst b/Doc/tutorial/datastructures.rst
> - >>> zip(*matrix)
> + >>> list(zip(*matrix))
> [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)]
Is there a reason we don't run the doctests in the Doc/ folder's .rst
files as part of regrtest (e.g. via DocFileSuite), or is that
something we just haven't gotten around to doing?
On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
> changeset: 78485:0a75ce232f56
> user: Brett Cannon <brett(a)python.org>
> date: Fri Aug 10 12:21:12 2012 -0400
> Issue #15502: Finish bringing importlib.abc in line with the current
> + cache used by the finder. Used by :func:`invalidate_caches()` when
Minor style nit: the Dev Guide says not to include the trailing
parentheses in :func: text:
"func: The name of a Python function; dotted names may be used. The
role text should not include trailing parentheses to enhance
(from http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l888 )
(though I don't know why the Dev Guide says the opposite for :c:func:
and is silent on :meth:.)
On a related note: this may not be common knowledge, but it is
possible to hyperlink to a function definition while still showing
different text (in particular passed arguments) by using the following
This is in the Dev Guide, but I haven't seen the construct used in
many places where it seems like it would be helpful and appropriate.
currently the only cheap way for developers to test on SPARC that I'm
aware of is using this old Debian qemu image:
That image still uses linuxthreads and may contain any number of platform
bugs. It is currently impossible to run the test suite without bus errors,
Could someone with access to a SPARC machine (perhaps with a modern version
of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
the test suite?
Also, it would be really nice if someone could donate a SPARC buildbot.
could someone please add a sentence to PEP 366 that describes the actual
content of the new "__package__" attribute (and thus, the PEP)?
I had to read through almost the entire document to be assured that
"__package__" is really supposed to contain a string and I had a hard time
nailing down its content. The only real hint in there is the example, and
even that is ambiguous.
Please change the first paragraph in the "proposed change" section to this:
The major proposed change is the introduction of a new module level
[NEW]string[/NEW] attribute, __package__.[NEW:] It contains the fully
qualified name of the package that the module lives in, without the module
name itself[/NEW]. When it is present, ...