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
We're going to go ahead and cut the 2.6.6rc1 release tonight, bugs.python.org
willing. We've got a fairly clean test run on local hardware across OS X,
Linux (Debian, Ubuntu), and Brian is looking at Windows now (the buildbots are
a sad and sorry story). Ezio has done a great amount of work on getting 2.6.6
pretty clean with -3 warnings too.
Please consider the release26-maint tree closed for commits (except svnmerges)
for the next 2.5 hours. I'll send another message at about 2200 UTC when I
freeze the tree for those commits too. You can request exceptions by pinging
me on #python-dev or (if you're feeling lucky ;) sending me an email.