Hello fellow Pythoneers and Pythonistas,
The source tarballs and Windows installers for the first (and hopefully only)
Python 2.6.6 release candidate is now available:
As usual, we would love it if you could download, install, and test these with
your favorite projects and environments. A truly impressive number of bug
have been fixed since Python 2.6.5, with the full NEWS file available here:
Barring complications, we expect to release Python 2.6.6 final on August 16,
Please note that with the release of Python 2.7 final on July 3, 2010, and in
accordance with Python policy, Python 2.6.6 is the last scheduled bug fix
maintenance release of the 2.6 series. Because of this, your testing of this
release candidate will help immensely. We will of course continue to support
security fixes in Python 2.6 for quite some time.
My thanks go out to everyone who has helped contribute fixes great and small,
and much testing and bug tracker gardening for Python 2.6.6. The excellent
folks on #python-dev are true Pythonic heros too.
(on behalf of the Python development community)
i face with problem when i run one sample on cygwin:
please help me
Exception happened during processing of request from ('127.0.0.1', 49154)
Traceback (most recent call last):
File "/usr/local/lib/python2.5/SocketServer.py", line 222, in handle_request
File "/usr/local/lib/python2.5/SocketServer.py", line 241, in process_request
File "/usr/local/lib/python2.5/SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/local/lib/python2.5/SocketServer.py", line 522, in __init__
File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 316, in handle
File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_req
File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 46, in do_GET
File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 175, in copyfile
File "/usr/local/lib/python2.5/shutil.py", line 29, in copyfileobj
File "/usr/local/lib/python2.5/socket.py", line 274, in write
File "/usr/local/lib/python2.5/socket.py", line 261, in flush
error: (113, 'Software caused connection abort')
I was made aware of this oddity here:
reffed = "xKITTENSx"[1:-1]
These strings are different, presumably because of the (ob_refcnt == 1) optimization used during object pickling.
This might come as a suprise to many, and is potentially dangerous if pickling is being used as precursor to some hashing function.
For example, we use code that caches function calls, using something akin to:
myhash = hash(cPickle.dumps(arguments))
cached_args, cached_value = cache[myhash]
if cached_args == arguments: return cached_value
value = Function(*args)
cache[myhash] = artuments, value
The non-uniqueness of the pickle string will cause unnecessary cache misses in this code. Pickling is useful as a precusor because it allows for more varied object types than hash() alone would.
I just wanted to point this out. We'll attempt some local workarounds here, but it should otherwise be simple to modify pickling to optionally turn off this optimization and always generate the same output irrespective of the internal reference counts of the objects.
For the most part, the information at
http://www.python.org/download/releases/2.4/msi/ assisted me with
automating a 2.7 installation on Windows XP. The following initial
attempt, however, failed to provide a working python installation.
(Messages are either "The system cannot execute the specified
program." or "This application has failed to start because the
application configuration is incorrect. Reinstalling the application
may fix this problem.")
msiexec /qb /i python-2.7.msi ALLUSERS=1 ADDLOCAL=Extensions
After looking through Tools/msi/msi.py, I was able to automate a
minimal and working Python installation with this adjustment:
Since the only reference I could find to the above web page was when
the MSI installer was first announced
(http://www.python.org/download/releases/2.4.2), the installer options
may have changed since then.
Would you check if my change is what you intended and perhaps migrate
the web page of the 2.4 release note to 2.7?
While Lib/_threading_local.py is meant as a fallback Python
implementation of thread-local objects, it looks like it will never be
invoked in practice. The reason is that the thread-local code in
Modules/_threadmodule.c in unconditionally compiled. Furthermore,
_threading_local.py imports threading which itself imports _thread, so
it's not possible for _threading_local to function if for some reason
_thread fails to build or import.
What should we do with _threading_local? Keep it as an example of a
Python implementation (which is vastly slower than what a C
implementation can do and also currently less robust), or plainly
[Since I received no replies on this in python-list, perhaps python-dev is
I've been tinkering with __code__.co_firstlineno for testing the trace.py
module (Python Issue 9315), and ran into an interesting problem. Consider
if __name__ == "__main__":
The first print out correctly specifies the line "def foo" is in. However,
the second one points to the line with "@dummydecorator" instead of "def
bar". [Python 2.6]
The side-effects of this behavior can be easily seen in the output of
modules like trace and profile. Would you say it's normal, or could this be
considered a bug?
Working with Catherine on an argparse bug, we ran into a test that was
apparently failing by raising a SystemExit, when the test harness was
supposed to be catching that error. It took us a bit to realize that
there wasn't really a SystemExit error, but that what we were seeing was
the SystemExit chained to the exception the test harness was purposfully
raising after catching the SystemExit. In Python2, only the second,
intentionally raised exception would be printed by unittest. In Python3,
the "main error" printed by unittest is the SystemExit, and the error
raised by the test harness appears after the "while processing the above
error" sentence. Needless to say, this is a bit confusing.
So I thought I'd break the exception chain before raising the error the
test harness really wants to raise. However, I can't figure out any way
to do that. Am I missing something, or this a missing feature?
R. David Murray www.bitdance.com