I'm liking where we're at for Python 2.6.6. We have no release blocker issues
open, and the buildbots look about as green as they get. I've accounted for
all the commits since 2.6.6rc1 and I think barring any last minute issues,
that we're on schedule for 2.6.6 final for this Monday, August 16.
Please, no commits to release26-maint without checking with me first (svnmerge
blocks are okay). I plan to tag the release at approximately 2200 UTC Monday
so that Martin can build the Windows binaries first thing on Tuesday and I can
announce the release Tuesday afternoon EST.
I'll be hanging out on #python-dev as much as possible over the weekend in
case anything crops up.
Thanks to everybody who has helped get 2.6.6 to such an awesome state.
Based on a pair of tracker issues (#3445 and #9396) I'm considering a
couple of adjustments to functools.wraps for 3.2.
The first (#3445) is a request from ages ago to make update_wrapper
more forgiving when it encounters a missing attribute. Instead of
throwing AttributeError (as it does now), it would just skip the
missing attribute. This would allow wraps to be used with other
callables that don't fully mimic the function API. I was initially
opposed to the idea, but over time I've come to think this is a case
where practicality beats purity (since that really sums up
functools.wraps in general - it is already the case that the copied
info isn't quite right for the decorated function, but it's still
better than using the wrapper function's own metadata).
The second (#9396) came up in the context of the new cache decorators
added to functools, and allowing applications to choose their own
caching strategies. I suggested exposing the original (uncached)
function, and Raymond suggested that the easiest way to enable that
would be for functools.update_wrapper to add a new attribute that
provides a reference to the original function. Some time back, we
considered doing this automatically as an integral part of decoration,
but decided that wasn't appropriate. However, building it into the
explicit wrapping functions makes sense to me. To avoid namespace
conflicts, I plan to use "__wraps__" as the name for the reference to
the original function.
Thoughts? Concerns? Better ideas?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm happy to announce the
first alpha preview release of Python 3.2.
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
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger
For an extensive list of changes in 3.2, see Misc/NEWS in the Python
To download Python 3.2 visit:
3.2 documentation can be found at:
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.16 (GNU/Linux)
-----END PGP SIGNATURE-----
I would like to see “unit test needed” removed from the workflow menu in
the bug tracker. The reason is that we don't do test-driven development
(or, at least, most of us don't) and this stage entry is therefore
useless and confusing. Saying to someone that an unit test is needed
happens during the patch review - it isn't a separate stage in itself.
The reason I'm asking is that I've seen some triagers bumping a lot of
issues to “unit test needed” lately, and I find this annoying. What we
need is patches, not unit tests per se.
Fred Drake fdrake at acm.org wrote:
> I'd like to see a more complete proposal, including:
> - what to do with Windows, Mac OS X
PEP 370 already specifies a directory for Python config files:
> user data directory
> Usually the parent directory of the user site directory. It's meant for Python version specific data like config files, docs, > images and translations.
> Unix (including Mac)
On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> +PS: In the standard Python distribution, this file is encoded in UTF-8
> +and the list is in rough alphabetical order by last names.
> David Abrahams
> Jim Ahlstrom
> @@ -28,6 +29,7 @@
> Éric Araujo
> Jason Asbahr
> David Ascher
> +Peter Åstrand
>From my recollection of the discussion when Peter was added, the first
character in his last name actually sorts after Z (despite its
resemblance to an A).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'm trying to add a '?' token to the parser, and weird things
I've added a #define to token.h, an entry to _PyParser_TokenNames
in tokenizer.c and case for it in PyToken_OneChar(). But it's
behaving as though the tokenizer is not recognising my token.
I put in some printfs to find out whether PyToken_OneChar() is
recognising it. The results are confusing: while running
pgen, PyToken_OneChar() is being called and recognising the
new token correctly.
However, it doesn't seem to be getting called *at all* when
parsing Python code. I don't see how this can happen, because
pgen seems to use the same tokenizing code as Python itself.
Is there anything else I need to do? Does some file need
to be manually re-made?