Mailman 3 April 2007 - Python-Dev

Summary of Tracker Issues
by Tracker 08 Apr '07

08 Apr '07

ACTIVITY SUMMARY (04/01/07 - 04/08/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1647 open ( +0) / 8584 closed ( +0) / 10231 total ( +0) Average duration of open issues: 758 days. Median duration of open issues: 707 days. Open Issues Breakdown open 1647 ( +0) pending 0 ( +0)

1 0

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures opt (1)
by Raymond Hettinger 06 Apr '07

06 Apr '07

I believe the failures started with Facundo Batista's checkin on April 4th: ------------------------------------- Author: facundo.batista Date: Wed Apr 4 16:10:40 2007 New Revision: 54681 Modified: python/trunk/Lib/test/test_socket_ssl.py Log: Fixed the way that the .pem files are looked for, and changed how to kill the process in win32 to use the _handle attribute. Modified: python/trunk/Lib/test/test_socket_ssl.py ----- Original Message ----- From: Brett Cannon To: nnorwitz(a)gmail.com Cc: python-checkins(a)python.org Sent: Friday, April 06, 2007 11:27 AM Subject: Re: [Python-checkins] Python Regression Test Failures opt (1) On 4/6/07, Neal Norwitz <nnorwitz(a)gmail.com> wrote: [SNIP] test_socket_ssl test test_socket_ssl failed -- Traceback (most recent call last): File "/tmp/python-test/local/lib/python2.6/test/test_socket_ssl.py", line 117, in testBasic self.assertEqual (i, "Foo\n") AssertionError: 'ERRO' != 'Foo\n' test_socketserver test_socketserver skipped -- Use of the `network' resource not enabled test_softspace test_sort Exception in thread Thread-43: Traceback (most recent call last): File "/tmp/python-test/local/lib/python2.6/threading.py", line 460, in __bootstrap self.run() File "/tmp/python-test/local/lib/python2.6/test/test_socket_ssl.py", line 163, in run self.s.stdin.write(l) IOError: [Errno 32] Broken pipe Anyone know what caused these two tests to start failing? -Brett ------------------------------------------------------------------------------ _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins

1 0

context manager - generator interaction?
by Bob Sidebotham 06 Apr '07

06 Apr '07

The interaction shown below feels like a bug, or at least very much a trap for the unwary. It's some sort of interaction between a context manager and a generator, both of which can raise StopIteration. The code is excised from a real application, so it's a bit artificial looking. Nevertheless, it represents an entirely natural evolution of some code (whereby the call to a context manager was added deep within the code). Since it seems to work with open as the context manager, but not with my own null context manager defined with context_manager(), it feels like this is probably a bug in contextmanager(). I did look in the archives, and it's possible this has been raised before, but I wasn't clear on that. So apologies in advance if this is already understood. This is using the stock distribution of python 2.5 on Linux 2.4. Comments? Bob Sidebotham bash-2.05b$ cat test.py from __future__ import with_statement def gen(): return# Should cause stop iteration yield # Just to make this a generator, for this example # This works as expected. try: gen().next() # Should immediately raise StopIteration except StopIteration: print "Part 1: should reach here!" else: print "Part 1: shouldn't reach here!" # Now try the same thing, but with a context manager wrapping the generator call. # This also works as expected. try: with open("/etc/passwd") as pw: gen().next() except StopIteration: print "Part 2: should reach here!" else: print "Part 2: shouldn't reach here!" # Finally, try this with our own home grown null context manager. # This does not work as expected. from contextlib import contextmanager @contextmanager def ctxt(): yield try: with ctxt(): gen().next() except StopIteration: print "Part 3: should reach here!" else: print "Part 3: shouldn't reach here!" bash-2.05b$ python test.py Part 1: should reach here! Part 2: should reach here! Part 3: shouldn't reach here! bash-2.05b$

11 12

Re: [Python-Dev] context manager - generator interaction?
by Phillip J. Eby 05 Apr '07

05 Apr '07

At 03:54 PM 4/5/2007 -0400, Bob Sidebotham wrote: >The interaction shown below feels like a bug, or at least very much a >trap for the unwary. It's some sort of interaction between a context >manager and a generator, both of which can raise StopIteration. The >code is excised from a real application, so it's a bit artificial >looking. Nevertheless, it represents an entirely natural evolution of >some code (whereby the call to a context manager was added deep within >the code). Since it seems to work with open as the context manager, >but not with my own null context manager defined with >context_manager(), it feels like this is probably a bug in >contextmanager(). It actually appears to be a quirk in the "with" machinery itself, that only affects generator context managers because of their need to handle StopIteration specially. If you rewrite your context manager as a class with __enter__ and __exit__, the problem will go away. Checking what was happening via pdb, I found that the contextmanager's __exit__ is being called with a "value" of None, rather than with an exception *instance*. This fouls up GeneratorContextManager.__exit__'s special handling for StopIteration -- which was apparently never tested by any unit tests. I can see a few different ways to work around the problem in GeneratorContextManager itself, the simplest of which is to add these two lines right before the self.gen.throw() call: if type is StopIteration and value is None: value = type() It seems to me that this is a bit of a kludge, but trying to make it so that __exit__ always gets called with an instance is much more of a pain since it appears that the None a performance enhancement for simple errors like StopIteration, that avoids creating an instance.

1 0

branch is frozen for release of 2.5.1c1 (and 2.5.1)
by Anthony Baxter 05 Apr '07

05 Apr '07

Please stay out of the 2.5 branch unless you're one of the release team - I'm cutting 2.5.1c1 at the moment. There will be a 2.5.1 final next week, assuming all goes well. If you have an urgent bugfix you need in, please post here and get someone to approve it before the checkin! Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Distutils and -framework on MacOSX
by Greg Ewing 04 Apr '07

04 Apr '07

Has anyone found a way of persuading distutils to pass MacOSX -framework options properly when linking? Using extra_link_args doesn't work, because they need to be at the beginning of the command line to work properly, but extra_link_args gets put at the end. And extra_compile_args is only used when compiling, not linking. -- Greg

2 4

A Survey on Defect Management Practices in Free/Open Source Software
by Anu Gupta DCSA 04 Apr '07

04 Apr '07

Dear Python Contributors, I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study on practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta(a)pu.ac.in anugupta98(a)gmail.com

10 9

Re: [Python-Dev] test_socketserver flakey?
by Guido van Rossum 04 Apr '07

04 Apr '07

I'm not sure I agree with your analysis -- the test that fails is using unix domain sockets, not TCP. On 4/3/07, Hasan Diwan <hasan.diwan(a)gmail.com> wrote: > Guido: > > On 03/04/07, Guido van Rossum <guido(a)python.org> wrote: > > But I saw this failure during a regular regrtest run as well. How > > would you suggest to fix this?i > > > > You'll need to make the connect/close lines into a critical section and have > execution suspended for the TCP wait time. It defaults to 60 seconds on BSD > sockets, but I'm not aware of the constant for it (a quick survey of the > header files doesn't show anything promising). On the other hand, I don't > think you're going to be running this particular test a number of times > quickly (or will you?). In the final examination, I suspect it's a race > condition. > -- > Cheers, > > Hasan Diwan <hasan.diwan(a)gmail.com> > -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 1

About SSL tests
by Facundo Batista 04 Apr '07

04 Apr '07

There's this bug (#451607) about the needing of tests for socket SSL... Last interesting update in the tracker is five years ago, and since a lot of work has been done in test_socket_ssl.py (Brett, Neal, Tim, George Brandl). Do you think is useful to leave this bug opened? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

10 25

Re: [Python-Dev] test_socketserver flakey?
by Guido van Rossum 03 Apr '07

03 Apr '07

On 4/3/07, Guido van Rossum <guido(a)python.org> wrote: > On 4/3/07, Hasan Diwan <hasan.diwan(a)gmail.com> wrote: > > > Guido van Rossum wrote: > > > > The test_socketserver unittest seems to be failing occasionally for > > > > me. (Svn HEAD, Ubuntu dapper.) > > > > Specifically, which test is failing? > > Hard to say -- so far, I've just seen the blanket "test failed" report > from regrtest.py, occasionally. The few times I ran the test directly > it passed. I'll try running it in a loop to see what happens. OK, did that, after a bunch of iterations it failed like this: ADDR = @test17637 CLASS = SocketServer.UnixStreamServer server created server running test client 0 test test_socketserver crashed -- <class 'socket.error'>: (2, 'No such file or directory') Traceback (most recent call last): File "../Lib/test/regrtest.py", line 557, in runtest_inner indirect_test() File "/usr/local/google/home/guido/python/trunk/Lib/test/test_socketserver.py", line 212, in test_main testall() File "/usr/local/google/home/guido/python/trunk/Lib/test/test_socketserver.py", line 200, in testall testloop(socket.AF_UNIX, streamservers, MyStreamHandler, teststream) File "/usr/local/google/home/guido/python/trunk/Lib/test/test_socketserver.py", line 144, in testloop testfunc(proto, addr) File "/usr/local/google/home/guido/python/trunk/Lib/test/test_socketserver.py", line 62, in teststream s.connect(addr) File "<string>", line 1, in connect error: (2, 'No such file or directory') -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Python-Dev April 2007