On behalf of the Python development team, I'm happy as a clam to announce the
immediate availability of Python 2.7.1.
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, auto-numbering of fields in the str/unicode format method,
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.1 visit:
The 2.7.1 changelog is at:
2.7 documentation can be found at:
This is a production release. Please report any bugs you find to the bug
benjamin at python.org
(on behalf of the entire python-dev team and 2.7.1's contributors)
On Thu, Nov 25, 2010 at 4:12 PM, terry.reedy <python-checkins(a)python.org> wrote:
> The :class:`SequenceMatcher` class has this constructor:
> -.. class:: SequenceMatcher(isjunk=None, a='', b='')
> +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True)
> Optional argument *isjunk* must be ``None`` (the default) or a one-argument
> function that takes a sequence element and returns true if and only if the
> @@ -340,6 +349,9 @@
> The optional arguments *a* and *b* are sequences to be compared; both default to
> empty strings. The elements of both sequences must be :term:`hashable`.
> + The optional argument *autojunk* can be used to disable the automatic junk
> + heuristic.
Catching up on checkins traffic, so a later checkin may already fix
this, but there should be a versionchanged tag in the docs to note
when the autojunk parameter was added.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
During the make step of python, I am encountering a weird error. This is on
AIX 5.3 using gcc as the compiler.
My configuration options are as follows
./configure --enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I
/opt/freeware/include -I /opt/freeware/include/readline -I
/opt/freeware/include/ncurses" LDFLAGS="-L. -L/usr/local/lib"
Below is the transcript from the make step.
ldd: /lib/libreadline.a: File is an archive.
INFO: Can't locate Tcl/Tk libs and/or headers
building '_struct' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/u01/home/apli/wm/GDD/Python-2.6.6/./Include -I.
-IInclude -I./Include -I/opt/freeware/include
./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp -L. -L/usr/local/lib
-L. -L/usr/local/lib -lpython2.6 -o build/lib.aix-5.3-2.6/_struct.so
*Fatal Python error: Interpreter not initialized (version mismatch?)*
*make: 1254-059 The signal code from the last command is 6.*
The last command that i see above (ld_so_aix) seems to have completed as the
file _struct.so exists after this command and hence I am not sure which step
There is no other Python version on my machine.
> Author: senthil.kumaran
> Mouse support and colour to Demo/curses/life.py by Dafydd Crosby
Okay, this time I’m reacting to the right branch <wink>
> Modified: python/branches/py3k/Demo/curses/life.py
> --- python/branches/py3k/Demo/curses/life.py (original)
> +++ python/branches/py3k/Demo/curses/life.py Thu Nov 25 15:56:44 2010
> @@ -1,6 +1,7 @@
> #!/usr/bin/env python3
> # life.py -- A curses-based version of Conway's Game of Life.
> # Contributed by AMK
> +# Mouse support and colour by Dafydd Crosby
Shouldn’t his name rather be in Misc/ACKS too? Modules typically
(warning: non-scientific data) include the name of the author or first
contributors but not the name of every contributor.
I think these cool features deserve a note in Misc/NEWS too :)
Re: “colour”: the rest of the file use US English, as do the function
names (see for example curses.has_color). It’s good to use one dialect
consistently in one file.
I was recently surprised to learn that chr(i) can produce a string of
length 2 in python 3.x. I suspect that I am not alone finding this
behavior non-obvious given that a mistake in Python manual stating the
contrary survived several releases.  Note that I am not arguing
that the change was bad. In Python 2.x, \U escapes have been
producing surrogate pair on narrow builds for a long time if not since
introduction of unicode. I do believe, however that a change like
this  and its consequences should be better publicized. I have not
found any discussion of this change in PEPs or "What's new" documents.
The closest find was a mentioning of a related issue #3280 in the 3.0
NEWS file.  Since this feature will be first documented in the
Library Reference in 3.2, I wonder if it will be appropriate to
mention it in "What's new in 3.2"?
On 11/23/2010 5:43 PM, Éric Araujo wrote:
>> Modified: python/branches/py3k/Misc/ACKS
>> --- python/branches/py3k/Misc/ACKS (original)
>> +++ python/branches/py3k/Misc/ACKS Tue Nov 23 21:32:47 2010
>> @@ -1,4 +1,4 @@
> This change introduced a so-called UTF-8 BOM in the file. Is
> TortoiseSvn the culprit or a text editor?
I used Notepad to edit the file, TortoiseSvn to commit, the same as I
did for #9222, rev86702, Lib\idlelib\IOBinding.py, yesterday.
If the latter is OK, perhaps *.py gets filtered better than misc. text
files. I believe I have the config as specified in dev/faq.
enable-auto-props = yes
* = svn:eol-style=native
*.c = svn:keywords=Id
*.h = svn:keywords=Id
*.py = svn:keywords=Id
*.txt = svn:keywords=Author Date Id Revision
Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
and only use Win32 WIDE API (ie: GetFileAttributesW)?
Mainly in posixmodule.c.
I think we can simplify the code hugely. (This means droping bytes
support for os.stat etc on windows)
# I recently did it for winsound.PlaySound with MvL's approval
PyPy 1.4: Ouroboros in practice
We're pleased to announce the 1.4 release of PyPy. This is a major breakthrough
in our long journey, as PyPy 1.4 is the first PyPy release that can translate
itself faster than CPython. Starting today, we are using PyPy more for
our every-day development. So may you :) You can download it here:
What is PyPy
PyPy is a very compliant Python interpreter, almost a drop-in replacement
for CPython. It's fast (`pypy 1.4 and cpython 2.6`_ comparison)
Among its new features, this release includes numerous performance improvements
(which made fast self-hosting possible), a 64-bit JIT backend, as well
as serious stabilization. As of now, we can consider the 32-bit and 64-bit
linux versions of PyPy stable enough to run `in production`_.
Numerous speed achievements are described on `our blog`_. Normalized speed
charts comparing `pypy 1.4 and pypy 1.3`_ as well as `pypy 1.4 and cpython 2.6`_
are available on benchmark website. For the impatient: yes, we got a lot faster!
* PyPy's built-in Just-in-Time compiler is fully transparent and
automatically generated; it now also has very reasonable memory
requirements. The total memory used by a very complex and
long-running process (translating PyPy itself) is within 1.5x to
at most 2x the memory needed by CPython, for a speed-up of 2x.
* More compact instances. All instances are as compact as if
they had ``__slots__``. This can give programs a big gain in
memory. (In the example of translation above, we already have
carefully placed ``__slots__``, so there is no extra win.)
* `Virtualenv support`_: now PyPy is fully compatible with
virtualenv_: note that
to use it, you need a recent version of virtualenv (>= 1.5).
* Faster (and JITted) regular expressions - huge boost in speeding up
the `re` module.
* Other speed improvements, like JITted calls to functions like map().
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _`Virtualenv support`:
.. _`in production`:
.. _`our blog`: http://morepypy.blogspot.com
.. _`pypy 1.4 and pypy 1.3`:
.. _`pypy 1.4 and cpython 2.6`:
Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski,
Amaury Forgeot d'Arc, Armin Rigo and the PyPy team
On Tue, Nov 23, 2010 at 2:18 PM, Amaury Forgeot d'Arc
>> Given the apparent difficulty of writing even basic text processing
>> algorithms in presence of surrogate pairs, I wonder how wise it is to
>> expose Python users to them.
> This was already discussed two years ago:
Thanks for the link. Let me summarize that discussion as I read it.
The discussion starts with a reference to Guido's 2001 post which concluded with
... if we had wanted to use a
variable-lenth internal representation, we should have picked UTF-8
way back, like Perl did. Moving to a UTF-16-based internal
representation now will give us all the problems of the Perl choice
without any of the benefits.
and proposes to move to USC-4 completely for Python 3.0. Note that
this is not the option that I would like to discuss here. I don't
propose to discuss abandoning narrow builds. Instead, I would like to
discuss the costs and benefits associated with using variable width
CES as an internal representation. This is where the 2008 discussion
moved. OP did not realize that narrow build supported UTF-16 and like
myself was surprised that application developers should be aware of
surrogates if they want to use narrow builds. It was also suggested
that Python itself is likely to have many bugs that can be triggered
by non-BMP characters on narrow builds. Guido's response was:
I'd also prefer to receive bug reports about breakages actually
encountered in the wild than purely theoretical issues
I don't think this is a good position to take. Programs that expect
one code unit where Python may produce two are likely to have security
holes. Even when programmers carefully sanitize their input, they are
likely to do it at the code point level based on Unicode category and
0xFFFF boundary does not mean anything special for their applications.
I think anyone who wants to write a robust application has two
choices in practice: (a) use wide Unicode build; (b) restrict all
text to BMP. Supporting surrogates at the application level is likely
to be prohibitively expensive.
It was later suggested that the main benefit of "UTF-16" builds is
that they can easily interface with system libraries that are "UTF-16"
based. However, how likely are these libraries be bug-free when it
comes to non-BMP characters? The history teaches us that not very
Daniel Arbuckle presented arguments against imposing the burden of
dealing with surrogates on application writers. 
The recurrent theme on the thread was that non-BMP characters are rare
and those who need them can afford the extra development cost
associated with the surrogates. This point was very eloquently
articulated by Guido:
Who are the many here? Who are the few? I'd venture that (at least for
the foreseeable future, say, until China will finally have taken over
the role of the US as the de-facto dominant super power :-) the many
are people whose app will never see a Unicode character outside the
BMP, or who do such minimal string processing that their code doesn't
care whether it's handling UTF-16-encoded data.
This argument can also be used to support the position that narrow
builds should not support non-BMP characters.
Later the discussion started resembling this thread when it went into
a scholastic dispute over fine points in Unicode Standard terminology.
Then BDFL vetoed len(u"\U00012345") returning 1 on narrow builds. 
I would be against that as well. I don't see len("\U00012345") == 2
as a big problem because application developers can simply avoid using
\U literals if they don't want to support non-BMP characters. On the
other hand, an option to warn users about non-BMP literals on a narrow
build may be useful but it is easy to implement in lint-like tools.
There were multiple suggestions for standard library additions to help
application writers to deal with surrogate pairs, but as far as I can
tell, nothing has been done in this area in the following two years.
I don't think there is a recipe on how to fix legacy
character-by-character processing loop such as
for c in string:
to make it iterate over code points consistently in wide and narrow
builds. (Note that I am not asking for a grapheme iterator here.
This is clearly an application level feature.)
> So yes, wrap() and center() should be fixed.
I opened an issue 10521 for that.  I am fully prepared to see it
dismissed as "theoretical" and be closed with "won't fix" or linger
indefinitely. Fixing it would most likely involve writing the second
version of pad() utility function specifically for the narrow build.
All examples I've seen in Python C code of dealing with surrogates
came with hand-coded #ifndef Py_UNICODE_WIDE fragments and no
user-friendly macros or APIs that would abstract it away.
A quick grep for maxunicode in the standard library revealed only one
case of "narrow-build aware" code:
if sys.maxunicode != 65535:
# XXX: negation does not work with big charsets
See Lib/sre_compile.py. Not exactly a model to follow.
To conclude, I feel that rather than trying to fully support non-BMP
characters as surrogate pairs in narrow builds, we should make it
easier for application developers to avoid them. If abandoning
internal use of UTF-16 is not an option, I think we should at least
add an option for decoders that currently produce surrogate pairs to
treat non-BMP characters as errors and handle them according to user's