Mailman 3 November 2010 - Python-Dev

Re: [Python-Dev] r86351 - python/branches/py3k/Lib/tempfile.py
by Antoine Pitrou 09 Nov '10

09 Nov '10

On Tue, 9 Nov 2010 04:43:58 +0100 (CET) raymond.hettinger <python-checkins(a)python.org> wrote: > Author: raymond.hettinger > Date: Tue Nov 9 04:43:58 2010 > New Revision: 86351 > > Log: > Simplify code > > Modified: > python/branches/py3k/Lib/tempfile.py > > Modified: python/branches/py3k/Lib/tempfile.py > ============================================================================== > --- python/branches/py3k/Lib/tempfile.py (original) > +++ python/branches/py3k/Lib/tempfile.py Tue Nov 9 04:43:58 2010 > @@ -108,30 +108,19 @@ > > _RandomNameSequence is an iterator.""" > > - characters = ("abcdefghijklmnopqrstuvwxyz" + > - "ABCDEFGHIJKLMNOPQRSTUVWXYZ" + > - "0123456789_") > + characters = "abcdefghijklmnopqrstuvwxyz0123456789_" Aren't you reducing entropy here?

2 1

GUI test runner tool
by Michael Foord 09 Nov '10

09 Nov '10

Hello all, Now that unittest has test discovery, Mark Roddy has been working on resurrecting the old GUI test runner (using Tkinter): https://bitbucket.org/markroddy/unittestgui This was part of the original pyunit project but I believe it was never part of the standard library: http://sourceforge.net/projects/pyunit/ Here's a screenshot of what it looks like: http://skitch.com/fuzzyman/dhu9r/pyunit I'd like to propose adding it to Python in Tools/ and am volunteering to maintain it. If the answer is "not yet" that is fine as it can go into unittest2 first. Mark has updated it to work with test discovery and added support for configuring test discovery in the same way as you can from the command line. It is a nice tool for those new to writing tests who aren't yet familiar with the command line or prefer a GUI. In its basic form you simply pick a directory and unittestgui will discover and run all the tests it finds. It would be nice if it provided more diagnostic information on tests it ran (clicking through test results) but these can be added later. All the best, Michael Foord -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

5 5

rlcompleter -- auto-complete dictionary keys (+ tests)
by Valery Khamenya 09 Nov '10

09 Nov '10

Hi, A) I missed the auto-complete feature for dictionary keys a lot in python console. This patch seems to do the job. B) There is no rlcompleter tests in trunk for some reason. So, I've taken the 2.7.x test_rlcompleter.py and extended it. C) patched rlcompleter as such works OK for unicode dictionary keys as well. All tests pass OK. HOWEVER, readline's completion mechanism seem to be confused with unicode strings -- see comments to Completer.dict_key_matches(). So, perhaps, some changes should be applied to readline code too. Attached: 1. rlcompleter.py (as for trunk) 2. test_rlcompleter (as for trunk) 3. rlcompleter_trunk_to_new.diff (created as: diff rlcompleter_trunk.py rlcompleter.py >rlcompleter_trunk_to_new.diff) P.S. thanks to kerio & ssbr on icq for advices. best regards -- Valery A.Khamenya

2 3

Backward incompatible API changes in the pydoc module
by Nick Coghlan 09 Nov '10

09 Nov '10

All, I was about to commit the patch for issue 2001 (the improvements to the pydoc web server and the removal of the Tk GUI) when I realised that pydoc.serve() and pydoc.gui() are technically public standard library APIs (albeit undocumented ones). Currently the patch switches serve() to start the new server implementation and gui() to start the server and open a browser window for it. It occurred to me that, despite the "it's an application" feel to the pydoc web server APIs, it may be a better idea to leave the two existing functions alone (aside from adding DeprecationWarning), and using new private function names to start the new server and the web browser. Is following the standard deprecation procedure the better course here, or am I being overly paranoid? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 8

Re: [Python-Dev] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
by David Bolen 09 Nov '10

09 Nov '10

On Sat, Nov 6, 2010 at 7:19 AM, Victor Stinner <victor.stinner(a)haypocalc.com> > > I noticed "OSError: [Errno 23] Too many open files in system" errors on your > FreeBSD buildbot. I would like to know if you configured a limit on the open > files or maybe of child processes on this buildbot or not, or if it is a > failure in Python? > > The first error always occurs in the first test of test_concurrent_futures. It's > maybe because this test uses a lot of open files or processes? I couldn't find the matching failures that you're talking about, but then I figured out you mean the FreeBSD7 (7.2) buildbot, not the FreeBSD (6.4) buildbot .... I haven't configured any specific limits with respect to open files. On both FreeBSD buildbots, kern.maxfiles is 3600 and kern.maxfilesperproc is 3060. Both have limits of 1530 processes. The latter also agrees with the maximum descriptors as shown by limit. In regards to R. David Murray's response, the buildbots are VMs with limited memory, so the dynamic calculation he references for descriptors is much lower than his system. Looks like the reason FreeBSD is ok, and FreeBSD7 is because the relevant tests don't run due to lack of POSIX semaphore support. I manually enabled their use on FreeBSD7 a while back (11/2009, issue7272) since they aren't on by default. I'd be surprised if at least test_multiprocessing didn't pass at that point (since that's what the issue was for) but even it seems to be generating the open files error now. The buildbots haven't changed, but I suppose the tests might just have grown in the number of files they need over time. I noticed that the failures seem to always be on a semaphore call. Some quick googling found a few references that seems to imply that the number of posix semaphores are very limited (like 30), and can't be changed without recompiling the kernel from source. So that's not so big a threshold for the tests to have perhaps started crossing since issue7272 was fixed. Certainly seems more likely than 3000+ files or 1500+ processes. I wonder if it's possible to deduce if this started recently or not? The web buildbot interface doesn't go back that far, and an additional complexity is that the FreeBSD builds tend to have various errors somewhat consistently over time, but perhaps there are server logs we can grep for this particular error? Not sure if the best approach at this point is to see if the tests can use fewer semaphores, skip these tests under FreeBSD 7 like 6, or if it's important enough to compile a new kernel with a higher semaphore limit. -- David

3 6

Re: [Python-Dev] [Python-checkins] r86327 - in python/branches/py3k: Doc/includes/email-mime.py Doc/includes/email-simple.py Doc/library/smtplib.rst Doc/whatsnew/3.2.rst Lib/smtplib.py Lib/test/test_smtplib.py Misc/NEWS
by Éric Araujo 08 Nov '10

08 Nov '10

> Author: r.david.murray > New Revision: 86327 > > Log: #10321: Add support for sending binary DATA and Message objects to smtplib > > Modified: python/branches/py3k/Doc/includes/email-mime.py > ============================================================================== > # Send the email via our own SMTP server. > s = smtplib.SMTP() > -s.sendmail(me, family, msg.as_string()) > +s.sendmail(msg) > s.quit() If I’m not mistaken, you’re giving a message object to a method that only accepts str or bytes. That line should read s.send_message(msg). Regards

1 0

Re: [Python-Dev] [issue1633863] AIX: configure ignores $CC
by Sébastien Sablé 08 Nov '10

08 Nov '10

Hi Martin, I have started to correct quite a lot of issues I have with Python on AIX, and since I had to test quite a lot of patchs, I though it would be more convenient to setup a buildbot for that platform. So I now have a buildbot environment with 2 slaves (AIX 5.3 and 6.1) that builds and tests Python (branch py3k) with both gcc and xlc (the native AIX compiler) (I have 4 builders ("py3k-aix6-xlc", "py3k-aix5-xlc", "py3k-aix6-gcc", "py3k-aix5-gcc"). I expect to add 4 more builders for branch 2.7 in coming days. I would like to share the results of this buildbot to the Python community so that issues with AIX could be addressed more easily. R. David Murray pointed me to the page on the python wiki concerning buildbot. It is stated there that is is possible to connect some slaves to some official Python buildbot master. Unfortunately, I don't think this solution is possible for me: I don't think the security team in my company would appreciate that a server inside our network runs some arbitrary shell commands provided by some external source. Neither can I expose the buildbot master web interface. Also I had to customize the buildbot rules in order to work with some specificities of AIX (see attached master.cfg), and I can't guarantee that this buildbot will run 24 hours a day; I may have to schedule it only once at night for example if it consumes too much resources. (And the results are very unstable at the moment, mostly because of issue 9862). On the other hand, I could upload the build results with rsync or scp somewhere or setup some MailNotifier if that can help. How do you think I could share those results? regards -- Sébastien Sablé Le 15/09/2010 23:28, R. David Murray a écrit : > > R. David Murray added the comment: > > Sébastien, you could email Martin (tracker id loewis) about adding your buildbot to our unstable fleet (or even to stable if it is stable; that is, the tests normally pass and don't randomly fail). As long as you are around to help fix bugs it would be great to have an aix buildbot in our buildbot fleet. > > (NB: see also http://wiki.python.org/moin/BuildBot, which unfortunately is a bit out of date...) > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker<report(a)bugs.python.org> > <http://bugs.python.org/issue1633863> > _______________________________________

7 16

Re: [Python-Dev] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
by "Martin v. Löwis" 08 Nov '10

08 Nov '10

> Remove one trace of Mac OS 9 support (#7908 follow-up) > > This was overlooked in r80804. This change is not really a bug fix, I'm skeptical that this change should be carried out, then. It's easy to argue that this can't possibly hurt (but I can certainly come up with code that will break under that change); however, I fail to see what good it does. Regards, Martin

4 6

Re: [Python-Dev] [Python-checkins] r86300 - in python/branches/py3k: Misc/NEWS PC/winsound.c
by Éric Araujo 08 Nov '10

08 Nov '10

> Author: hirokazu.yamamoto > New Revision: 86300 > Log: > Issue #6317: Now winsound.PlaySound only accepts unicode with MvL's approval. > > > Modified: python/branches/py3k/Misc/NEWS > ============================================================================== > --- python/branches/py3k/Misc/NEWS (original) > +++ python/branches/py3k/Misc/NEWS Sun Nov 7 15:29:26 2010 > @@ -251,6 +251,8 @@ > Extension Modules > ----------------- > > +- Issue #6317: Now winsound.PlaySound only accepts unicode. > + > - Issue #6317: Now winsound.PlaySound can accept non ascii filename. Shouldn’t that be only one entry? Regards

1 0

Re: [Python-Dev] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py
by Antoine Pitrou 08 Nov '10

08 Nov '10

On Sat, 6 Nov 2010 19:03:53 +0100 (CET) eric.araujo <python-checkins(a)python.org> wrote: > Author: eric.araujo > Date: Sat Nov 6 19:03:52 2010 > New Revision: 86276 > > Log: > Fix #10252 again (hopefully definitely). Patch by Brian Curtin. It seems this and previous fixes should be backported to 2.7. Regards Antoine.

3 3