Please review issue 2375 , which is an enhancement request to add a
PYTHON3PATH environment variable. Because we have elected to have both
a python and a python3 command, I think this is an issue worth thinking
about carefully to make sure we are serving the Python user community
and easing the transition to python3. It could be that "use virtualenv"
is the best answer, but I feel we should think about it carefully to
make sure that is really true.
R. David Murray www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls
On behalf of the Python development team and the Python community, I'm
happy to announce the release candidate 1 of Python 2.5.5.
This is a source-only release that only includes security fixes. The
last full bug-fix release of Python 2.5 was Python 2.5.4. Users are
encouraged to upgrade to the latest release of Python 2.6 (which is
2.6.4 at this point).
This releases fixes issues with the logging and tarfile modules, and
with thread-local variables. See the detailed release notes at the
website (also available as Misc/NEWS in the source distribution) for
details of bugs fixed.
For more information on Python 2.5.5, including download links for
various platforms, release notes, and known issues, please see:
Highlights of the previous major Python releases are available from
the Python 2.5 page, at
Enjoy this release,
Martin v. Loewis
Python Release Manager
(on behalf of the entire python-dev team)
In October 2009 I created PEP 391 to propose a new method of configuring logging using dictionaries:
In November 2009 I posted to this list that the PEP was ready for review.
I have had numerous helpful comments from some of you, and I have incorporated most of them into updates to the PEP. Though I have the feeling from community discussions that the PEP has been generally favourably received - well I would think that, wouldn't I? ;-) - I've not asked for a vote and so I don't know the state of community consensus regarding this PEP.
So, can you please indicate your vote for or against incorporating PEP 391 into Python? It would be nice if I could incorporate the changes before 2.7a3 is released! Ideally, I would like to check in the changes unless there are objections to doing so. All those who think that logging is currently hard to configure will benefit from these changes, so here's the opportunity to pipe up and improve things.
Thanks & regards,
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
The current description is " Windows AMD64 binary".
All the best,
-------- Original Message --------
Subject: Download Page - AMD64
Date: Fri, 11 Dec 2009 04:03:16 -0600
From: Thomas Brownback <thomas.brownback(a)gmail.com>
Should I use the AMD64 version of Python on an Intel 64 chip? I know
those 64-bit implementations are very similar, but are they similar
enough that your AMD64 will work on Intel?
If so, perhaps a note should be placed on that page to help avoid
confusion. Explicit being better than implicit and all.
Thanks for your time,
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On behalf of the Python development team, I'm gleeful to announce the second
alpha release of Python 2.7.
Python 2.7 is scheduled to be the last major version in the 2.x series. It
includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement syntax, improved float repr, and the
memoryview object have been backported from 3.1. Other features include an
ordered dictionary implementation, unittests improvements, and support for ttk
Tile in Tkinter. For a more extensive list of changes in 2.7, see
http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python
To download Python 2.7 visit:
Please note that this is a development release, intended as a preview of new
features for the community, and is thus not suitable for production use.
The 2.7 documentation can be found at:
Please consider trying Python 2.7 with your code and reporting any bugs you may
2.7 Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should be there and I did a
blog post on this topic recently:
* argparse (PEP 389)
* brief mention on still wanting to break out the stdlib from CPython
* an official policy on extension modules? (i.e. must have a pure Python
implementation which can mean a ctypes implementation unless given an
That's everything from a stdlib perspective. I have half-baked ideas, but
nothing concrete enough to bring up unless people really want to discuss
stuff like how to potentially standardize module deprecation warnings, etc.
In terms of me personally, I do plan to bring up at some point during the
summit these points which don't squarely fit during my time slot:
* an official unofficial policy on how new proposed features should come to
us (i.e. working code to python-ideas with a shell of a PEP that includes
abstract and motivation -> hashed out PEP to python-dev -> pronouncement)
* any changes needed to the issue tracker to help with the workflow? (stage
field seems like a failed experiment and we now have several effective
triage people who can help w/ guiding changes)
If there is something missing from the stdlib discussion that you think
should be brought up at the summit let me know. And if there is something
here you want to discuss before the summit let me know and I can start a
separate thread on it.
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour should be
retained by default in case any existing software depends on it. My
question is: should my regex module still do this for Python 3?
Speaking personally, I'd like it to behave correctly, and Python 3 is
the version where backwards-compatibility is allowed to be broken.
Secondly, Python 2 is reaching the end of the line and Python 3 is the
future. Should I still release a version that works with Python 2? I'm
thinking that it could be confusing if new regex module did zero-width
splits correctly in Python 3 but not in Python 2. And also, should I
release it only for Python 3 as a 'carrot'?
Finally, the module allows some extra backslash escapes, eg \g<name>, in
the pattern. Should it treat ill-formed escapes, eg \g, as it would have
treated them in the re module?
Consider this program:
def __init__(self, name):
self.name = name
def __set__(self, instance, what):
instance.__dict__[self.name] = what
attr = Descr("attr")
x = X()
x.attr = 42
It gives in output:
<__main__.Descr object at 0x7fe1c9b28150>
The documentation  says that Descr is a data descriptor because it
defines the __set__ method. It also states that data descriptors
always override the value in the instance dictionary. So, the second
line should also be the descriptor object according to the
My question is: Is this a doc bug or a implementation bug? If the
former, it will be the description of a data descriptor much less
consistent, since it will require that a __get__ method be present,
too. If the latter, the fix may break some programs relying on the
ability to "cache" a value in the instance dictionary.