FYI: I've just added the text below to the "What's New" document for
2.7. I wanted to describe how 2.7 will probably be maintained, but
didn't want to write anything that sounded like an iron-clad guarantee
of a maintenance timespan. Does this text seem like a reasonable set
Python 2.7 is intended to be the last major release in the 2.x series.
Though more major releases have not been absolutely ruled out, the
Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x.
Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of
maintenance compared to earlier 2.x versions. Python 2.7 will
continue to be maintained while the transition to 3.x is in
progress, and that transition will itself be lengthy. Most 2.x
versions are maintained for about 4 years, from the first to the
last bugfix release; patchlevel releases for Python 2.7 will
probably be made for at least 6 years.
* Because 2.7 will be running production applications, a policy
decision was made to silence warnings only of interest to developers
by default. Silencing :exc:`DeprecationWarning` and its descendants
prevents users from seeing warnings triggered by an application.
(Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or you can add
``warnings.simplefilter('default')`` to your code.
I'll just do a single entry saying that the static analyzer was used and not
list the files.
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
On May 3, 2010 4:00 PM, "Antoine Pitrou" <solipsis(a)pitrou.net> wrote:
Benjamin Peterson <benjamin <at> python.org> writes:
> 2010/5/3 Brett Cannon <brett <at> python.org>:
> > When I check in these changes I will do it file by file, but my
> > how to handle M...
Indeed. At most a single NEWS entry sounds sufficient.
Python-Dev mailing list
On behalf of the Python development team, I'm elated to announce the second beta
release of Python 2.7.
Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version
in the 2.x series. 2.7 will have an extended period of bugfix maintenance.
2.7 includes many features that were first released in Python 3.1. The faster
io module, the new nested with statement syntax, improved float repr, set
literals, dictionary views, and the memoryview object have been backported from
3.1. Other features include an ordered dictionary implementation, unittests
improvements, a new sysconfig module, 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:
While this is a development release and is thus not suitable for production use,
we encourage Python application and library developers to test the release with
their code and report any bugs they encounter to:
2.7 documentation can be found at:
2.7 Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)
It looks like we're moving ahead with removing tabs. Was there consensus
Last I saw Antoine had written a script that might do what we want, but
hadn't been thoroughly tested. Now I've seen a few checkins for files
that have been run through the script.
What gives? And why do this so close to 2.7? I don't think it will cause
any problems, but it's hard to review commits to ensure they have no
changes when there's a rush of large commits near a release.
Has anyone considered using regrtest's -j option in the buildbot
configuration to speed up the test runs? Antoine Pitrou pointed out
that even for single CPU slaves, this could be a win due to the number
of tests that spend time sleeping or waiting on I/O. And on slaves with
multiple CPUs it would clearly be even better. eg, I don't know what
hardware is actually in the Solaris slave (bot loewis-sun), but if it
has the full 4 UltraSPARCs that it could, then running with -j4 or -j5
there might bring its runtime down from nearly 100 minutes to 20 or 25 -
competitive with some of the more reasonable slaves.
Saturday eve (us, eastern).
Last night I had intermittent problems with bugs.python.org: issues not
being fetched, submissions not being recorded. David Abrahams reported
'bugs.python.org seems to be down' is his urlparse thread.
Right not, I have a fetch and submission 'loading' for over a minute,
after fetching an issue a minute before. The new beta2 page came up with
The submission just stopped with
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /issue8641.
Reason: Error reading from remote server
Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9
OpenSSL/0.9.8g Server at bugs.python.org Port 80
Hey, everybody... I'm Catherine, a database administrator who makes up
excuses to write Python instead.
I'm not actually here as a core developer, but as somebody who hopes to
become a developer and recruit some more, which brings me to my question:
Who lives close enough to Ohio to make it to PyOhio this summer? I want to
use PyOhio to create new Python devs (including myself), but I need some
existing ones to seed the process.
I need a few veterans (3?) who can commit to come to PyOhio and take part as
audience/instructors in a "Teach Me [Python core / standard library]
Bugfixing" session. (See
PyOhio Call for Proposals is up May 10 so I'd better find you quick!
I'm pretty much ignorant enough to lead a Teach Me session. In a Teach Me
session, the person at the projector *doesn't* know the material. Instead,
she asks the audience questions ("How do I find a bug to work on?"), and
they talk her through it. It's based on Teach Me Twisted, a mind-blowing
session Steve Holden led at PyCon 2008 (
http://catherinedevlin.blogspot.com/2008/03/teach-me-twisted.html). I think
it's a fantastic way to teach, but it depends on some veterans being in the
audience. There are folks in the greater Python community eager to get hold
of a video of such a session... if we do this well, it could become an
important tool in keeping the quality of core Python code high.
And all I need from you, my audience-instructors, is a promise to show up
(no preparation necessary). Can you make it? Can you pass the appeal on to
others you know of?
Thanks! Hope to see you in July!
*** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org ***
Python 3.0 introduced PyUnicode_DecodeFSDefault() and
PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to
UTF-8 if getting the file system encoding failed or the encoding is unknown
(there is not nl_langinfo(CODESET) function).
UTF-8 is not a good choice for the fallback because it's incompatible with
other encodings like Latin1. I would like to fallback to ASCII on error which
is compatible with all encodings (thanks to surrogateescape).
I would like to ensure that sys.getfilesystemencoding() result cannot be None,
because Python 3.2 uses it on Unix to decode os.environb and to encode
filenames in subprocess. I can implement a fallback for os.environb and
subprocess (and other functions calling sys.getfilesystemencoding()), but I
prefer to have a reliable sys.getfilesystemencoding() function.
This change doesn't concern Windows and Mac OS X because the encoding is
hardcoded (mbcs, utf-8). On Unix, I don't know in which case nl_langinfo() can
fail. Empty environment is not an error: nl_langinfo(CODESET) returns "ascii".
I think that few (or no) user would notice this change.