Mailman 3 August 2009 - Python-Dev

PyCon 2010: Call for Proposals
by Jesse Noller 13 Aug '09

13 Aug '09

Yup! It's that time again, I'm encouraging anyone involved in core development, or wanting to talk about core development - or python-core internals to submit talk proposals. Lots of people have expressed interest in such talks. -jesse Call for proposals -- PyCon 2010 -- <http://us.pycon.org/2010/> =============================================================== Due date: October 1st, 2009 Want to showcase your skills as a Python Hacker? Want to have hundreds of people see your talk on the subject of your choice? Have some hot button issue you think the community needs to address, or have some package, code or project you simply love talking about? Want to launch your master plan to take over the world with python? PyCon is your platform for getting the word out and teaching something new to hundreds of people, face to face. Previous PyCon conferences have had a broad range of presentations, from reports on academic and commercial projects, tutorials on a broad range of subjects and case studies. All conference speakers are volunteers and come from a myriad of backgrounds. Some are new speakers, some are old speakers. Everyone is welcome so bring your passion and your code! We're looking to you to help us top the previous years of success PyCon has had. PyCon 2010 is looking for proposals to fill the formal presentation tracks. The PyCon conference days will be February 19-22, 2010 in Atlanta, Georgia, preceded by the tutorial days (February 17-18), and followed by four days of development sprints (February 22-25). Online proposal submission is open now! Proposals will be accepted through October 1st, with acceptance notifications coming out on November 15th. For the detailed call for proposals, please see: <http://us.pycon.org/2010/conference/proposals/> For videos of talks from previous years - check out: <http://pycon.blip.tv> We look forward to seeing you in Atlanta!

1 0

Re: [Python-Dev] [issue6673] Py3.1 hangs in coroutine and eats up all memory
by Stefan Behnel 13 Aug '09

13 Aug '09

[moving this from the bug tracker] Alexandre Vassalotti wrote: > Alexandre Vassalotti added the comment: > > Not a bug. > > The list comprehension in your chunker: > > while True: > target.send([ (yield) for i in range(chunk_size) ]) > > is equivalent to the following generator in Python 3: > > while True: > def g(): > for i in range(chunk_size): > yield (yield) > target.send(list(g())) > > This clearly needs not what you want. Does this do anything meaningful, or would it make sense to output a compiler warning (or better: an error) here? Using yield in a comprehension (as opposed to a generator expression, which I intuitively expected not to work) doesn't look any dangerous at first glance, so it was quite surprising to see it fail that drastically. This is also an important issue for other Python implementations. Cython simply transforms comprehensions into the equivalent for-loop, so when we implement PEP 342 in Cython, we will have to find a way to emulate CPython's behaviour here (unless we decide to stick with Py2.x sematics, which would not be my preferred solution). Stefan > So, just rewrite your code using for-loop: > > while True: > result = [] > for i in range(chunk_size): > result.append((yield)) > target.send(result) > > ---------- > nosy: +alexandre.vassalotti > resolution: -> invalid > status: open -> closed

3 4

www/svn python.org status update
by A.M. Kuchling 12 Aug '09

12 Aug '09

The following sites are up again on a new machine, but cannot be updated through SVN hooks or whatever mechanism: www.python.org docs.python.org www.jython.org planet.python.org planet.jython.org svn.python.org was deliberately not brought up again. The backups were a few hours behind and missing the ~10 most recent commits. Not disastrous, but it could probably mess up people's SVN trees, so after some IRC discussion, the decision was to wait until the original disks are available again. That will probably not occur until Monday, maybe Tuesday. I've disabled donations to the PSF through credit cards, which pointed to a CGI script that doesn't currently work; PayPal donations still work. Do we want to make any edits to the 3.1 or 3.0 pages about the I/O bug? I can do that manually if someone will provide the text and/or a patch to put up. Unfortunately without SVN we probably can't cut a new 3.1 release, unless Benjamin or someone has a really up-to-date copy of the Mercurial tree and wants to work from that. --amk

9 12

Study on communication and collaboration in software development teams
by Martin Gelhaus 12 Aug '09

12 Aug '09

Dear Python developer, within the scope of my diploma thesis at the University of Paderborn, Germany, with the title "Study about communication and collaboration in software development in teams" I am conducting a survey of members of software development teams. I would be very grateful if you help me in my studies and answer the survey at http://thales.cs.upb.de/limesurvey185/index.php?lang=en&sid=91192&token=kkz… This is the official description of the survey: In the last years many means of communication and collaboration were introduced in software projects to assist the development teams with their daily work. With this study we want to identify requirements for a communication- and collaboration-supporting platform for software development. For this purpose we will evaluate the utilization and effectiveness of different means of communication and collaboration in solving software and managerial problems in software development teams. The survey will take about 10-15 minutes and contains 55 questions that cover various topics. Many thanks for your support of my research. If there are any further questions, don't hesitate to contact me. Best regards from Paderborn, Germany Martin Gelhaus (gelhaus(a)uni-paderborn.de) ---------------------------------------------- Click here to do the survey: http://thales.cs.upb.de/limesurvey185/index.php?lang=en&sid=91192&token=kkz… ---- Martin Gelhaus Graduand at Didactics of Informatics chair at University of Paderborn Fürstenallee 11 Room F2.416 D-33102 Paderborn

1 0

issue 6654
by Kristján Valur Jónsson 10 Aug '09

10 Aug '09

I added http://bugs.python.org/issue6654 I also put a not to python-ideas but have had no response yet. Any comments? Here's the summary: I've created http://codereview.appspot.com/100046 on Rietveld: by passing the "path" component of the xmlrpc request to the dispatch method, itbecomes possible to dispatch differently according to this. This patch providesthat addition. Additionally, it provides an MultiPathXMLRPCDispatcher mixin class and a MultiPathXMLRPCServer that uses it, to have multiple dispatchers for different paths. This allows a single server port to serve different XMLRPC servers as differentiated by the HTTP path. A test is also preovided. Kristján

3 3

3.1.1 plan
by Benjamin Peterson 10 Aug '09

10 Aug '09

Once Subversion is back up (today, tomorrow?), I will tag the 3.1 maintence branch as 3.1.1rc1. The tree will remain frozen until Saturday. If at that time, no one has found something wrong with the RC, I will retag it as the final bugfix release. -- Regards, Benjamin

2 2

codecs.oen [was: PEP 385: the eol-type issue]
by Jim Jewett 10 Aug '09

10 Aug '09

> M.-A. Lemburg wrote: >> ... and because of this, the feature is already available if >> you use codecs.open() instead of the built-in open(): Neil Hodgson asked: > So should I not add an issue for the basic open because codecs.open > should be used for this case? In python 3, why does codecs.open even still exist? As best I can tell, codecs.open should be the same as regular open, but for a unicode file -- and all text files are treated as unicode in python 3.0 So at this point, are there any differences beyond: (a) The builtin open doesn't work on multi-byte line-endings other than the multi-character CRLF. (In other words, it goes by the traditional Operating System conventions developed when a char was a byte, but the Unicode standard allows for a few more possibilities, which are currently rare in practice.) (b) The codecs version is much slower, because it hasn't seen the optimization effort. -jJ

2 1

statement vs expression [was: (try-except) conditional expression similar to (if-else) conditional (PEP 308)]
by Jim Jewett 09 Aug '09

09 Aug '09

> Kristján Valur Jónsson wrote: >> I've never understood the need to have a distinction betwen statements >> and expressions, not when expressions can have side effects. Alex Martelli responded: > If you're interested in understanding it better, research > Query-Command Separation (QCS), e.g. starting at > http://en.wikipedia.org/wiki/Command-query_separation Either you missed Kristján's point, or your answer was so subtle that I missed yours. QCS makes it easy to determine which pieces of code (queries) are free of side-effects. I see value in that for both debugging and optimization. What I don't see is how that relates to expressions vs statements **when expressions can have side effects.** (Actually, in Python, I would say that statements are far *more* likely to be free of side-effects, as they are often there for flow control.) -jJ

1 0

hi everyone
by malathi selvaraj 09 Aug '09

09 Aug '09

I am new one to this mailing list I would like to learn python.. how to join IRC for python,i try it like #python, but i dn't get can you tell me -- Regards, S.Malathi.

5 4

www, svn.python.org down
by A.M. Kuchling 07 Aug '09

07 Aug '09

Both www.python.org and svn.python.org are down. They're hosted on the same machine, and it seems to have run into disk problems and hasn't rebooted even after power-cycling. Thomas Wouters will be visiting the machine physically tomorrow to try to diagnose the problem. (The machine also hosts planet.python.org and hg.python.org.) --amk

1 0

socket.makefile and EINTR handling
by Gregory P. Smith 07 Aug '09

07 Aug '09

In particular this issue: http://bugs.python.org/issue1628205 I believe we should handle EINTR internally within the socket._fileobject wrapper as nobody using a file-like object should ever expect to get an EINTR. EINTR only comes from using the lowest level system calls. Anyone strongly disagree? -gps

1 0

Summary of Python tracker Issues
by Python tracker 07 Aug '09

07 Aug '09

ACTIVITY SUMMARY (07/31/09 - 08/07/09) Python 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. 2315 open (+39) / 16175 closed (+16) / 18490 total (+55) Open issues with patches: 919 Average duration of open issues: 657 days. Median duration of open issues: 411 days. Open Issues Breakdown open 2283 (+39) pending 31 ( +0) Issues Created Or Reopened (55) _______________________________ heapq.nsmallest and nlargest should be smarter/more usable/more 07/31/09 CLOSED http://bugs.python.org/issue6614 created jab multiprocessing logging support test 08/01/09 http://bugs.python.org/issue6615 created OG7 PyList_APPEND (append without incref) 08/01/09 CLOSED http://bugs.python.org/issue6616 created ideasman42 patch During compiling python 3.1 getting error Undefined symbol libin 08/01/09 http://bugs.python.org/issue6617 created thoratsandip Typo in a listing in 5.2.9 of language reference 08/01/09 CLOSED http://bugs.python.org/issue6618 created gregorlingl Remove duplicated function in Lib/inspect.py 08/01/09 CLOSED http://bugs.python.org/issue6619 created vincele patch Variable may be used before first being assigned to in Lib/local 08/01/09 CLOSED http://bugs.python.org/issue6620 created vincele patch [RFC] Remove leftover use of Carbon module from Lib/binhex.py 08/01/09 CLOSED http://bugs.python.org/issue6621 created vincele patch [RFC] wrong variable used in Lib/poplib.py 08/01/09 CLOSED http://bugs.python.org/issue6622 created vincele patch Lib/ftplib.py netrc class parsing problem 08/01/09 http://bugs.python.org/issue6623 created vincele patch PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail 08/01/09 CLOSED http://bugs.python.org/issue6624 created jafo UnicodeEncodeError on pydoc's CLI 08/02/09 http://bugs.python.org/issue6625 created christoph patch show Python mimetypes module some love 08/02/09 http://bugs.python.org/issue6626 created jrus patch threading.local() does not work with C-created threads 08/02/09 http://bugs.python.org/issue6627 created Nikratio IDLE freezes after encountering a syntax error 08/02/09 http://bugs.python.org/issue6628 created brian89 seek doesn't properly handle file buffer, leads to silent data c 08/03/09 CLOSED http://bugs.python.org/issue6629 created lorentey patch string.Template custom pattern not working 08/03/09 http://bugs.python.org/issue6630 created jcollado urlparse.urlunsplit() can't handle relative files (for urllib*.o 08/03/09 http://bugs.python.org/issue6631 created albert Include more fullwidth chars in the decimal codec 08/03/09 http://bugs.python.org/issue6632 created ezio.melotti No handlers could be found for logger 08/03/09 CLOSED http://bugs.python.org/issue6633 created purpleidea sys.exit() called from threads other than the main one: undocume 08/03/09 http://bugs.python.org/issue6634 created jgehrcke Profiler doesn't print usage (indexError instead) 08/03/09 http://bugs.python.org/issue6635 created pr0gg3d patch Non-existant directory in sys.path prevents further imports 08/03/09 http://bugs.python.org/issue6636 created cemasoniv non-empty defaultdict .copy() fails returning empty dict 08/03/09 CLOSED http://bugs.python.org/issue6637 created tomcl optparse parse_args argument references wrong 08/04/09 http://bugs.python.org/issue6638 created kq1quick turtle: _tkinter.TclError: invalid command name ".10170160" 08/04/09 http://bugs.python.org/issue6639 created srid urlparse should parse mailto: URL headers as query parameters 08/04/09 http://bugs.python.org/issue6640 created mykmelez strptime doesn't support %z format ? 08/04/09 http://bugs.python.org/issue6641 created eka returning after forking a child thread doesn't call Py_Finalize 08/04/09 http://bugs.python.org/issue6642 created rnk patch joining a child that forks can deadlock in the forked child proc 08/04/09 http://bugs.python.org/issue6643 created rnk patch cmathmodule.c: Extra comma in enum - fails on AIX 08/04/09 CLOSED http://bugs.python.org/issue6644 created srid multiprocessing build fails on AIX - /dev/urandom (or equivalent 08/04/09 http://bugs.python.org/issue6645 created srid test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999 08/05/09 http://bugs.python.org/issue6646 created srid warnings.catch_warnings is not thread-safe 08/05/09 http://bugs.python.org/issue6647 created gagenellina codecs documentation does not mention surrogateescape 08/05/09 CLOSED http://bugs.python.org/issue6648 created Nikratio idlelib/rpc.py missing exit status on exithook 08/05/09 http://bugs.python.org/issue6649 created gpolo patch sre_parse contains a confusing generic error message 08/05/09 http://bugs.python.org/issue6650 created torne patch Py3k's posixpath.relpath not compatible with ntpath.relpath 08/05/09 http://bugs.python.org/issue6651 created erickt missing cmath functions 08/05/09 CLOSED http://bugs.python.org/issue6652 created pfeldman(a)verizon.net Potential memory leak in multiprocessing 08/05/09 http://bugs.python.org/issue6653 created jnoller Add "path" to the xmrlpc dispatcher method 08/05/09 http://bugs.python.org/issue6654 created krisvale etree iterative find[text] 08/06/09 http://bugs.python.org/issue6655 created Digitalxero patch locale.format_string fails on escaped percentage 08/06/09 http://bugs.python.org/issue6656 created christoph patch Copy documentation section 08/06/09 http://bugs.python.org/issue6657 created Sheepherd typo in buffer api docs 08/06/09 CLOSED http://bugs.python.org/issue6658 created ash buffer c-api: memoryview object documentation 08/06/09 http://bugs.python.org/issue6659 created ash Desire python.org documentation link to user contribution wiki ( 08/06/09 CLOSED http://bugs.python.org/issue6660 created keenethery Transient test_multiprocessing failure 08/06/09 http://bugs.python.org/issue6661 created pitrou HTMLParser.HTMLParser doesn't handle malformed charrefs 08/07/09 http://bugs.python.org/issue6662 created dayveday re.findall does not always return a list of strings 08/07/09 http://bugs.python.org/issue6663 created pfeldman(a)verizon.net readlines should understand Line Separator and Paragraph Separat 08/07/09 http://bugs.python.org/issue6664 created nyamatongwe fnmatch fails on filenames containing \n character 08/07/09 http://bugs.python.org/issue6665 created rajcze List of dirs to ignore in trace.py is applied only for the first 08/07/09 http://bugs.python.org/issue6666 created bogdan.opanchuk patch logging config - using of FileHandler's delay argument? 08/07/09 http://bugs.python.org/issue6667 created maro locale.py: can't parse sr_RS@latin locale 08/07/09 http://bugs.python.org/issue6668 created VPeric Issues Now Closed (32) ______________________ Backport set comprehensions 506 days http://bugs.python.org/issue2334 alexandre.vassalotti 26backport Extension module build fails for MinGW: missing vcvarsall.bat 465 days http://bugs.python.org/issue2698 tarek PyCF_DONT_IMPLY_DEDENT can be used to activate the with statemen 378 days http://bugs.python.org/issue3438 gpolo patch Include Tcl/Tk 8.5.4 in the windows binary for the upcoming beta 352 days http://bugs.python.org/issue3600 gpolo Arrows key do not browse in the IDLE 313 days http://bugs.python.org/issue3961 gpolo IDLE.app (Mac) File Menu MIssing Options 249 days http://bugs.python.org/issue4432 gpolo multiprocessing.JoinableQueue task_done() issue 234 days http://bugs.python.org/issue4660 jnoller bug fix to prevent io.BytesIO from accepting arbitrary keyword a 149 days http://bugs.python.org/issue5449 alexandre.vassalotti patch OverflowError in RLock.acquire() 12 days http://bugs.python.org/issue6562 davidar Make Decimal constructor accept all unicode decimal digits in in 4 days http://bugs.python.org/issue6595 marketdickinson patch urllib2 bug on CentOS 5 days http://bugs.python.org/issue6596 rpetrov test_distutils subtest test_get_exe_bytes fails depending on exe 3 days http://bugs.python.org/issue6604 tarek patch smtplib.SMTP.sendmail() rejected after quit(),connect() sequence 6 days http://bugs.python.org/issue6605 amaury.forgeotdarc HTMLParser cannot deal with mixture of arbitrary data and charac 1 days http://bugs.python.org/issue6611 liudongmiao(a)gmail.com heapq.nsmallest and nlargest should be smarter/more usable/more 0 days http://bugs.python.org/issue6614 rhettinger PyList_APPEND (append without incref) 1 days http://bugs.python.org/issue6616 rhettinger patch Typo in a listing in 5.2.9 of language reference 2 days http://bugs.python.org/issue6618 georg.brandl Remove duplicated function in Lib/inspect.py 1 days http://bugs.python.org/issue6619 marketdickinson patch Variable may be used before first being assigned to in Lib/local 3 days http://bugs.python.org/issue6620 marketdickinson patch [RFC] Remove leftover use of Carbon module from Lib/binhex.py 1 days http://bugs.python.org/issue6621 marketdickinson patch [RFC] wrong variable used in Lib/poplib.py 5 days http://bugs.python.org/issue6622 marketdickinson patch PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail 0 days http://bugs.python.org/issue6624 jafo seek doesn't properly handle file buffer, leads to silent data c 4 days http://bugs.python.org/issue6629 pitrou patch No handlers could be found for logger 2 days http://bugs.python.org/issue6633 purpleidea non-empty defaultdict .copy() fails returning empty dict 1 days http://bugs.python.org/issue6637 rhettinger cmathmodule.c: Extra comma in enum - fails on AIX 0 days http://bugs.python.org/issue6644 marketdickinson codecs documentation does not mention surrogateescape 1 days http://bugs.python.org/issue6648 georg.brandl missing cmath functions 0 days http://bugs.python.org/issue6652 georg.brandl typo in buffer api docs 0 days http://bugs.python.org/issue6658 georg.brandl Desire python.org documentation link to user contribution wiki ( 1 days http://bugs.python.org/issue6660 keenethery Mouse wheel crashes program 2102 days http://bugs.python.org/issue834351 gpolo add "reload" function to IDLE 1583 days http://bugs.python.org/issue1175686 gpolo Top Issues Most Discussed (10) ______________________________ 9 heapq.nsmallest and nlargest should be smarter/more usable/more 0 days closed http://bugs.python.org/issue6614 7 Include more fullwidth chars in the decimal codec 4 days open http://bugs.python.org/issue6632 6 [RFC] wrong variable used in Lib/poplib.py 5 days closed http://bugs.python.org/issue6622 5 show Python mimetypes module some love 5 days open http://bugs.python.org/issue6626 5 json C serializer performance tied to structure depth on some s 10 days open http://bugs.python.org/issue6594 5 OverflowError in RLock.acquire() 12 days closed http://bugs.python.org/issue6562 5 asyncore incorrect failure when connection is refused and using 16 days open http://bugs.python.org/issue6550 5 error: (10035, 'The socket operation could not complete without 466 days open http://bugs.python.org/issue2710 5 Backport set literals 508 days open http://bugs.python.org/issue2335 4 Desire python.org documentation link to user contribution wiki 1 days closed http://bugs.python.org/issue6660

1 0

PEP 385: the eol-type issue
by Dirkjan Ochtman 07 Aug '09

07 Aug '09

So, I've been not-working on this, which I feel bad about. Suffice it to say the day job has required more of my time then usual for the past few weeks. I want to get back into it, so let's start by re-raising this issue, which Mark Hammond conveniently summarized below. > On 4/07/2009 2:03 PM, Mark Hammond wrote: >> On 4/07/2009 12:30 PM, Nick Coghlan wrote: >>> And since Mercurial doesn't even allow us to say "this is a binary file" >>> the way CVS used to I'm currently not seeing any way for that to happen >>> except for win32text to be updated to correctly handle wild cards in >>> combination with negative filters. >> >> I agree with your conclusion. My ruminating on this over the last few >> months leaves me thinking this would involve: >> >> * my older 'accepted but then lost' hg patch to allow an explicit 'none' >> rule for a single file to override wildcards. This was and still is a good idea. It would be very nice if you could un-bitrot it and submit it for inclusion into crew-stable (so that it may land in the next release, which would hopefully be a somewhat near 1.3.2). >> * win32text be enhanced to use a normal versioned file in the root of >> the repo, much like hgingore, where a project can maintain project wide >> rules. I'm thinking that it should take stuff from .hgeols or whatever and apply rules from .hg/hgrc after that, so both may be used (and for backwards compatibility), but it sounds like a good idea in principle. >> * win32text be enhanced such that all python developers, regardless of >> platform, are willing to use this extension, even if the majority of >> files happen to use their native line ending (sauce for the goose is >> sauce for the gander, and all that...) I don't think that is necessary, I will elaborate below. >> * commit hooks be implemented to enforce this - but this should not be >> necessary if the above was implemented and socially enforced. You seem to advocate a two-step approach: enforce line endings through win32text, catch any errors that slipped through in a hook (commit hook is an optional first line of defense, changegroup hooks on the server to protect the rest of the world). I think inverting that approach would be better: have strict hooks on the server to prevent people from pushing inappropriate EOLs, and provide help on configuring win32text as an extra help for developers on Windows who use editors that work better with \r\n. That leaves people to pick their own weapon of choice against propagation of \r\n (e.g. better editor, commit hooks, whatever) while still making sure no inappropriate line endings land in the python.org repositories. It also seems to fit well with the whole consenting adults thing (but that might just be me). On Sun, Jul 19, 2009 at 15:27, Mark Hammond<skippy.hammond(a)gmail.com> wrote: > Sorry Dirkjan - I just noticed I didn't CC you on this mail originally. I'm > wondering if you have any more thoughts on these EOL issues and if there is > anything I can do to help? Taking up the 'none' filter, first, and .hgeols, secondly, in the win32text extension would be wonderfully helpful, since I don't do much development on Windows and am therefore not that familiar with the extension in the first place. Cheers, Dirkjan

18 82

Tkinter has many files
by cool-RR 07 Aug '09

07 Aug '09

Hello python-dev! I'm a Python programmer, but this is the first time I'm posting on python-dev, and I am not familiar at all with how the Python implementation works -- so this post may be way off. I've recently released a Python application, PythonTurtle<http://pythonturtle.com>, which is packaged using py2exe and InnoSetup. Due to the fact that my program needs to give the user a full Python shell, I've made py2exe package the entire Python standard library with my application. What I've noticed when I did that is that Tkinter has *a lot* of files. This is a bit inconvenient for several reasons, the main one being that the installer for PythonTurtle takes a long time to copy all of those little files. (I think the reason for the slowness is not the weight of the files, but the fact that there are so many of them.) There are also other reasons why it's annoying: Ohloh thinks my project is "Mostly written in Tcl," and git-gui gave me trouble for trying to commit so many files. Do you think it will be a good thing to package all of these Tkinter files into one big file (or several big files)? Best Wishes, Ram Rachum.

3 4

(try-except) conditional expression similar to (if-else) conditional (PEP 308)
by ilya 06 Aug '09

06 Aug '09

I took a look at the options 1 and 2: x = float(string) except float('nan') if ValueError y = float(string) except ValueError: float('nan') and I think this can be done just as easily with existing syntax: x = try_1(float, string, except_ = float('nan'), if_ = ValueError) y = try_2(float, string, { ValueError: float('nan') }) Here's the full example: ----- example starts ----- def try_1(func, *args, except_ = None, if_ = None): try: return func(*args) except if_ as e: return except_ def try_2(func, *args): 'The last argument is a dictionary {exception type: return value}.' dic = args[-1] try: return func(*args[:-1]) except Exception as e: for k,v in dic.items(): if isinstance(e, k): return v raise for string in ['5', 'five']: # x = float(string) except float('nan') if ValueError x = try_1(float, string, except_ = float('nan'), if_ = ValueError) # y = float(string) except ValueError: float('nan') y = try_2(float, string, { ValueError: float('nan') }) print(x, y) ----- example ends ----- As a side note, if I just subscribed to python-dev, is it possible to quote an old email? Below is my manual cut-and-paste quote: ---------- my quote -------------- Nick Coghlan wrote: > P.J. Eby wrote: >> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote: >>> [Jeffrey E. McAninch, PhD] >>>> I very often want something like a try-except conditional expression >>>> similar >>>> to the if-else conditional. >>>> >>>> An example of the proposed syntax might be: >>>> x = float(string) except float('nan') >>>> or possibly >>>> x = float(string) except ValueError float('nan') >>> +1 I've long wanted something like this. >>> One possible spelling is: >>> >>> x = float(string) except ValueError else float('nan') >> I think 'as' would be better than 'else', since 'else' has a different >> meaning in try/except statements, e.g.: >> >> x = float(string) except ValueError, TypeError as float('nan') >> >> Of course, this is a different meaning of 'as', too, but it's not "as" >> contradictory, IMO... ;-) > > (We're probably well into python-ideas territory at this point, but I'll > keep things where the thread started for now) > > The basic idea appears sound to me as well. I suspect finding an > acceptable syntax is going to be the sticking point. > > Breaking the problem down, we have three things we want to separate: > > 1. The expression that may raise the exception > 2. The expression defining the exceptions to be caught > 3. The expression to be used if the exception actually is caught > >>From there it is possible to come up with all sorts of variants. > > Option 1: > > Change the relative order of the clauses by putting the exception > definition last: > > x = float(string) except float('nan') if ValueError > op(float(string) except float('nan') if ValueError) > > I actually like this one (that's why I listed it first). It gets the > clauses out of order relative to the statement, but the meaning still > seems pretty obvious to me. > A further extension (if we need it): result = foo(arg) except float('inf') if ZeroDivisionError else float('nan') The 'else' part handles any other exceptions (not necessarily a good idea!). or: result = foo(arg) except float('inf') if ZeroDivisionError else float('nan') if ValueError Handles a number of different exceptions. > Option 2: > > Follow the lamba model and allow a colon inside this form of expression: > > x = float(string) except ValueError: float('nan') > op(float(string) except ValueError: float('nan')) > > This has the virtue of closely matching the statement syntax, but > embedding colons inside expressions is somewhat ugly. Yes, lambda > already does it, but lambda can hardly be put forward as a paragon of > beauty. > A colon is also used in a dict literal. > Option 3a/3b: > > Raymond's except-else suggestion: > > x = float(string) except ValueError else float('nan') > op(float(string) except ValueError else float('nan')) > [snip] -1

2 1

PEP 385: pruning/reorganizing branches
by Dirkjan Ochtman 05 Aug '09

05 Aug '09

So PEP 385 proposes to clean up the old branches we still have lying around in SVN. This list of branch: action items is what I've come up with to do this cleanup. Legend first: - keep-clone means we'll keep that branch in a separate clone - keep-named means we'll keep that branch as a named branch in one of the clones - strip means we won't keep that branch - streamed-merge means that it got merged by committing several new revisions to the other branch - merged-r* means the branch got merged in the named revision - merges? means I haven't checked/found out yet whether that branch was ever merged - ? means that your input would be even more helpful than for the other items - some items have no action yet, feel free to treat that as just '?' The actual List: py3k: keep-clone default: keep-clone tk_and_idle_maintenance: keep-clone release26-maint: keep-named release30-maint: keep-named pep-0383: keep-clone py3k-short-float-repr: strip streamed-merge multiprocessing-autoconf: keep-clone? release25-maint: keep-named io-c: keep-clone? py3k-issue1717: keep-clone tlee-ast-optimize: keep-clone release24-maint: keep-named empty: keep-clone? py3k-urllib: keep-clone tnelson-trunk-bsddb-47-upgrade: strip benjaminp-testing: strip py3k-importlib: keep-clone release23-maint: keep-named py3k-importhook: keep-clone ctypes-branch: strip decimal-branch: merged-r58143 bcannon-objcap: keep-clone? p3yk_no_args_on_exc: strip amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? release22-maint: keep-named theller_modulefinder: strip hoxworth-stdlib_logging-soc: strip partial tim-exc_sanity: merged-r46426 IDLE-syntax-branch: merged-r41480 strip-later ast-objects: strip ast-arena: merged-r41739 jim-doctest: strip ast-branch: merged-r39758 release23-branch: merges? jim-modulator: strip release21-maint: keep-named indexing-cleanup-branch: strip r23c1-branch: merged-r33637 r23b2-branch: merges? anthony-parser-branch: merged-r35460 r23b1-branch: merged-r32490 idlefork-merge-branch: strip getargs_mask_mods: strip cache-attr-branch: strip folding-reimpl-branch: strip streamed-merge r23a2-branch: merges? bsddb-bsddb3-schizo-branch: merged-r31008 r23a1-branch: merged-r30482 py-cvs-vendor-branch: strip DS_RPC_BRANCH: strip streamed-merge SourceForge: strip release22-branch: merged-r24921 r22rc1-branch: strip r22b2-branch: merges? merged-r24426 r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r22a2-branch: merged-r22674 descr-branch: merged-r22139 release20-maint: keep-named gen-branch: merged-r21181 iter-branch: merged-r20492 r161-branch: merges? cnri-16-start: strip universal-33: merges? None: strip avendor: strip Distutils_0_1_3-branch: strip partial release152p1-patches: merges? string_methods: merged-r13927 PYIDE: strip OSAM: strip PYTHONSCRIPT: strip BBPY: strip jar: merges? alpha100: strip streamed-merge unlabeled-2.36.4: strip partial unlabeled-2.1.4: strip partial unlabeled-2.25.4: strip partial fix-test-ftplib: merged-r66673 trunk-math: py3k-grandrenaming: okkoto-sizeof py3k-ctypes-pep3118: merged-r62597 trunk-bytearray: merged-r61936 libffi3-branch: merged-r61234 alex-py3k: strip cpy_merge: strip py3k-pep3137: merged-r58888 ../ctypes-branch: strip pep302_phase2: strip py3k-buffer: merged-r57181 p3yk-noslice py3k-struni p3yk: rename int_unification unlabeled-1.1.1: strip unlabeled-1.5.4: strip unlabeled-1.1.2: strip unlabeled-2.9.2: strip unlabeled-2.9.4: strip unlabeled-1.5.2: strip unlabeled-2.1.2: strip unlabeled-2.36.2: strip unlabeled-2.108.2: strip unlabeled-2.10.2: strip unlabeled-2.54.2: strip unlabeled-1.3.2: strip unlabeled-1.23.4: strip unlabeled-2.25.2: strip unlabeled-1.2.2: strip unlabeled-1.98.2: strip unlabeled-2.16.2: strip unlabeled-2.3.2: strip unlabeled-1.9.2: strip unlabeled-1.8.2: strip aimacintyre-sf1454481: merged-r46919 tim-current_frames: merged-r50541 bippolito-newstruct: merges? runar-longslice-branch: strip steve-notracing: strip rjones-funccall: merged-r46096 sreifschneider-newnewexcept: merged-r46456 tim-doctest-branch: merged-r36839 blais-bytebuf: strip ../bippolito-newstruct: rename rjones-prealloc: strip sreifschneider-64ints: strip stdlib-cleanup: strip ssize_t: merged-r42382 sqlite-integration: merged-r43514 tim-obmalloc: merged-r43059 Further actions: - implement branch map support in hgsubversion to be able to do named/unnamed/no branch on a branch-by-branch basis - implement splice map support in hgsubversion to be able to convert given merges to hg-native merge data Cheers, Dirkjan

8 8

Functionality in subprocess.Popen.terminate()
by Eric Pruitt 05 Aug '09

05 Aug '09

In my GSoC project, I have implemented asnychronous I/O in subprocess.Popen. Since the read/write operations are asynchronous, the program may have already exited by the time one calls the asyncread function I have implemented. While it returns the data just fine, I have come across an issue with the TerminateProcess function in Windows: if the program has already exited, when subprocess.Popen.Terminate calls the Windows built-in "TerminateProcess" function, an "access denied" error will occur. Should I just make it so that this exception is simply ignored or perform some kind of check to see if the process exists beforehand? If the latter, I have been unable to find a way to do so, to my liking at least. The solutions I saw would require code that seems a bit excessive to me. Eric

3 4

Mercurial migration: help needed
by "Martin v. Löwis" 05 Aug '09

05 Aug '09

This is a repost from a month ago. It didn't get much feedback last time. I have now two items. In this thread, I'd like to collect things that ought to be done but where Dirkjan has indicated that he would prefer if somebody else did it. Item 1 ------ The first item is build identification. If you want to work on this, please either provide a patch (for trunk and/or py3k), or (if you are a committer) create a subversion branch. It seems that Barry and I agree that for the maintenance branches, sys.subversion should be frozen, so we need actually two sets of patches: one that removes sys.subversion entirely, and the other that freezes the branch to the respective one, and freezes the subversion revision to None. Of course, it seems that the actual representation of branches hasn't been determined yet, so the build process integration may need to be changed if named branches aren't going to be used in the end. Anybody working on this should have good knowledge of the Python source code, Mercurial, and either autoconf or Visual Studio (preferably both). Item 2 ------ The second item is line conversion hooks. Dj Gilcrease has posted a solution which he considers a hack himself. Mark Hammond has also volunteered, but it seems some volunteer needs to be "in charge", keeping track of a proposed solution until everybody agrees that it is a good solution. It may be that two solutions are necessary: a short-term one, that operates as a hook and has limitations, and a long-term one, that improves the hook system of Mercurial to implement the proper functionality (which then might get shipped with Mercurial in a cross-platform manner). Regards, Martin

1 0

PEP 385: updating the PEP
by Dirkjan Ochtman 03 Aug '09

03 Aug '09

The diff below should reflect changes from the discussion we had last time. Please review. (Some comments may be more appropriate for the other threads I just kicked off.) Cheers, Dirkjan Index: pep-0385.txt =================================================================== --- pep-0385.txt (revision 74294) +++ pep-0385.txt (revision 74296) @@ -59,27 +59,25 @@ often has somewhat unintuitive results for people (though this has been getting better in recent versions of Mercurial). -I'm still a bit on the fence about whether Python should adopt cloned -branches and named branches. Since it usually makes more sense to tag releases -on the maintenance branch, for example, mainline history would not contain -release tags if we used cloned branches. Also, Mercurial 1.2 and 1.3 have the -necessary tools to make named branches less painful (because they can be -properly closed and closed heads are no longer considered in relevant cases). +The current proposal is to use named branches for release branches and adopt +cloned branches for feature branches, with one exception to this rule: the 3.x +branches will be kept in separate clones from the 2.x branches. I think this +provides an optimal hybrid approach for Python's uses of branching. -A disadvantage might be that the used clones will be a good bit larger (since -they essentially contain all other branches as well). This can me mitigated by -keeping non-release (feature) branches in separate clones. Also note that it's -still possible to clone a single named branch from a combined clone, by -specifying the branch as in hg clone http://hg.python.org/main/#2.6-maint. -Keeping the py3k history in a separate clone problably also makes sense. +Differences between named branches and cloned branches: -XXX To do: size comparison for selected separation scenarios. +* Tags in a different (maintenance) clone aren't available in the local clone +* Clones with named branches will be larger, since they contain more data +(The Mercurial book discourages the use of named branches, but it is, in this +respect, somewhat outdated. Named branches have gotten much easier to use +since that comment was written, due to improvements in hg.) + Converting branches ------------------- There are quite a lot of branches in SVN's branches directory. I propose to -clean this up a bit, by employing the following the strategy: +clean this up a bit, by following this basic strategy: * Keep all release (maintenance) branches * Discard branches that haven't been touched in 18 months, unless somone @@ -87,6 +85,21 @@ * Keep branches that have been touched in the last 18 months, unless someone indicates the branch can be deprecated +There's a `branch map`_ available that shows info about each branch: + +* keep-clone means we'll keep that branch in a separate clone +* keep-named means we'll keep that branch as a named branch in one of the clones +* strip means we won't keep that branch +* streamed-merge means that it got merged by committing several new revisions + to the other branch +* merged-r* means the branch got merged in the named revision +* merges? means I haven't checked/found out yet whether that branch was ever + merged +* ? means that your input would be even more helpful than for the other items +* some items have no action yet, feel free to treat that as just '?' + +.. _branch map: http://hg.python.org/pymigr/file/tip/all-branches.txt + Converting tags --------------- @@ -95,8 +108,8 @@ we should keep all release tags, and consider other tags for inclusion based on requests from the developer community. I'd like to consider unifying the release tag naming scheme to make some things more consistent, if people feel -that won't create too many problems. For example, Mercurial itself just uses -'1.2.1' as a tag, where CPython would currently use r121. +that won't create too many problems. The current proposal is to bring old +release tags in line with the current practice of release tag naming. Author map ---------- @@ -119,17 +132,19 @@ possible forms of pattern matching. The current Python repository already includes a rudimentary .hgignore file to help with using the hg mirrors. -It might be useful to have the .hgignore be generated automatically from -svn:ignore properties. This would make sure all historic revisions also have -useful ignore information (though one could argue ignoring isn't really -relevant to just checking out an old revision). +Since the current Python repository already includes a .hgignore file (for use +with hg mirrors), we'll just use that. Generating full history of the file +was debated but deemed impractical (because it's relatively hard with fairly +little gain, since ignoring is less important for older revisions). Revlog reordering ----------------- -As an optional optimization technique, we should consider trying a reordering -pass on the revlogs (internal Mercurial files) resulting from the conversion. -In some cases this results in dramatic decreases in on-disk repository size. +As an optional optimization technique, I have performed a reordering pass on +the revlogs (internal Mercurial files) resulting from the conversion. In some +cases this results in dramatic decreases in on-disk repository size. This +especially makes sense for the manifest (where it really helps out quite a lot) +and oft-edited files like NEWS.txt (with an admittedly smaller effect). Other repositories ------------------ @@ -138,7 +153,14 @@ converted. What other projects in the svn.python.org repository should be converted? Do we want to convert the peps repository? distutils? others? +There's now an initial stab at converting the Jython repository. The current +tip of hgsubversion unfortunately fails at some point. Pending investigation. +Other repositories that would like to converted to Mercurial can announce +themselves to me after the main Python migration is done, and I'll take care +of their needs. + + Infrastructure ============== @@ -165,18 +187,34 @@ lines. Open issue: do we check only the tip after each push, or do we check every commit in a changegroup? -* commit mails: we can leverage the notify extension for this +* commit mails: we can leverage the notify extension for this. Emails will + include diffs for each changeset committed against the repository. * buildbots: both the regular and the community build masters must be notified. Fortunately buildbot includes support for hg. I've also implemented this for Mercurial itself, so I don't expect problems here. * check contributors: in the current setup, all changesets bear the username of - committers, who must have signed the contributor agreement. In a DVCS, the - committers are not necessarily the same people who push, and so we can't - check if the committer is a contributor. We could use a hook to check if the - committer is a contributor if we keep a list of registered contributors. + committers, who must have signed the contributor agreement. We might want to + use a hook to check if the committer is a contributor if we keep a list of + registered contributors. Then, the hook might warn users that push a group + of revisions containing changesets from unknown contributors. +End-of-line conversions +----------------------- + +There has been some discussion about the lack of end-of-line conversion support +in Mercurial. While Mercurial comes with a win32text extension that provides +some basic support for converting end-of-line data on a file-name pattern +basis, the lack of exclusion (for specifying broad rules with exceptions) and +the use of hgrc files (which can't be versioned) make it less than ideal. + +I think the primary line of defense for prevention of inappropriate newlines +should be hooks on the server side which basically turn down any changegroup +or changeset introducing such data. The use of the win32text extension (which +can hopefully be improved/extended to support the usage scenarios mentioned +above) and/or a commit-time hook could be the first line of defense. + hgwebdir -------- @@ -185,7 +223,16 @@ build a quick extension to augment the URL rev parser so that it can also take r[0-9]+ args and come up with the matching hg revision. +roundup +------- +We'll come up with an auto-linking plugin for roundup, which can match a +changeset identifier (possibly with a branch prefix), and link it to the +appropriate revision in the hgwebdir instance. Second, the script above (in +the hgwebdir section) will make sure that old links to revision should continue +to work (by pointing to the hg changeset that reflects the svn revision). + + After migration =============== @@ -222,37 +269,32 @@ .. _wiki: http://www.selenic.com/mercurial/wiki/ .. _parts of the developer FAQ: http://www.python.org/dev/faq/#version-control -Think first, commit later? --------------------------- +Proposed workflow +----------------- -In recent history, old versions of Python have been maintained by a select -group of people backporting patches from trunk to release branches. While -this may not scale so well as the development pace grows, it also runs into -some problems with the current crop of distributed versioning tools. These -tools (I believe similar problems would exist for either git, bzr, or hg, -though some may cope better than others) are based on the idea of a Directed -Acyclic Graph (or DAG), meaning they keep track of relations of changesets. +I propose two workflows for the migration of patches between several branches. -Mercurial itself has a stable branch which is a ''strict'' subset of the -unstable branch. This means that generally all fixes for the stable branch -get committed against the tip of the stable branch, then they get merged into -the unstable branch (which already contains the parent of the new cset). This -provides a largely frictionless environment for moving changes from stable to -unstable branches. Mistakes, where a change that should go on stable goes on -unstable first, do happen, but they're usually easy to fix. That can be done by -copying the change over to the stable branch, then trivial-merging with -unstable -- meaning the merge in fact ignores the parent from the stable -branch). +For migration within 2.x or 3.x branches, I propose a patch always gets +committed to the oldest branch where it applies first. Then, the resulting +changeset can be merged using hg merge to all newer branches within that +series (2.x or 3.x). If it does not apply as-is to the newer branch, hg revert +can be used to easily revert to the new-branch-native head, patch in some +alternative version of the patch (or none, if it's not applicable), then commit +the merge. The premise here is that all changesets from an older branch within +the series are eventually merged to all newer branches within the series. -This strategy means a little more work for regular committers, because they -have to think about whether their change should go on stable or unstable; they -may even have to ask someone else (the RM) before committing. But it also -relieves a dedicated group of committers of regular backporting duty, in -addition to making it easier to work with the tool. +The upshot is that this provides for the most painless merging procedure. The +downside is that in the general case, people have to think about the oldest +branch to which the patch should be applied before actually applying it. -Now would be a good time to consider changing strategies in this regard, -although it would be relatively easy to switch to such a model later on. +For migration between 2.x and 3.x branches (which should all be in the same +direction, though I'm not sure what direction is most appropriate here), +changesets should be transplanted (not merged) in some other way. The +transplant extension, import/export and bundle/unbundle work equally well here. +Choosing this approach allows 3.x not to carry all of the 2.x history-since-it- +was-branched, meaning the clone is not as big and the merges not as complicated. + The future of Subversion ------------------------ @@ -281,7 +323,9 @@ I propose that the revision identifier will be the short version of hg's revision hash, for example 'dd3ebf81af43', augmented with '+' (instead of 'M') if the working directory from which it was built was modified. This mirrors -the output of the hg id command, which is intended for this kind of usage. +the output of the hg id command, which is intended for this kind of usage. The +sys.subversion value will also be renamed to sys.mercurial to reflect the +change in VCS. For the tag/branch identifier, I propose that hg will check for tags on the currently checked out revision, use the tag if there is one ('tip' doesn't

3 2

In late this am
by Casey Duncan 03 Aug '09

03 Aug '09

Going to the Dr., will be in thereafter. -Casey

1 1

pylinting the stdlib
by Vincent Legoll 03 Aug '09

03 Aug '09

Hello, I've fed parts of the stdlib to pylint and after some filtering there appears to be some things that looks strange, I've filled a few bugs to the tracker for them. 6623 Lib/ftplib.py netrc class parsing problem 6622 [RFC] wrong variable used in Lib/poplib.py 6621 [RFC] Remove leftover use of Carbon module from Lib/binhex.py 6620 Variable may be used before first being assigned to in Lib/locale.py 6619 Remove duplicated function in Lib/inspect.py Is this useless and taking reviewer's time for nothing ? Please advise, if this is deemed useful, I'll continue further -- Vincent Legoll

2 2

standard library mimetypes module pathologically broken?
by Jim Jewett 02 Aug '09

02 Aug '09

[It may be worth creating a patch; I think most of these comments would be better on the bug-tracker.] (1) In a few cases, it looked like you were changing parameter names between "files" and "filenames". This might break code that was calling it with keyword arguments -- as I typically would for this type of function. (1a) If you are going to change the .sig, you might as well do it right, and make the default be "knownfiles" rather than the empty tuple. (2) The comment about why inited was set true at the beginning of the function instead of the end should probably be kept, or at least reworded. (3) Default values: (3a) Why the list of known files going back to Apache 1.2, in that order? Is there any risk in using too *new* of a MimeTypes file? I would assume that the goal is to pick up whatever changes the user has made locally, but in that case, it still makes sense to have the newest file be the last one read, in case Apache has made bugfixes. (3b) Also, this would improve cross-platform consistency; if I read that correctly, the Apache files will override the python defaults on unix or a mac, but not on windows. That will change the results on the majority of items in _common_types. (application vs text, whether to put an x- in front of the word pict.) (3c) rtf is listed in non-standard, but http://www.iana.org/assignments/media-types/ does define it. (Though whether to guess application vs text is not defined, and python chooses differently from apache.) (3d) jpg is listed as non-standard. It turns out that this is just for the inverse mapping, where image/jpg is non-standard (for image/jpeg) but that is worth a comment. (see #5) (3e) In _types_map, the lines marked duplicates are duplicate keys, not duplicate values; it would be more clear to also comment out the (first) line itself, instead of just marking it a duplicate. (Or better yet, to mention that it is just being added for the inverse mapping, if that is the case.) (4) Why bother to lazyinit? Is there any sane usecase for a MimeTypes that hasn't been inited? I see value in not reading the default files, but none in not reading at least the files that were asked for. I could see value in only partial initialization if there were several long steps, but right now, initialization is all-or-nothing. If the thing is useless without an init, then it makes sense to just get done it immediately and skip the later checks; anyone who could have actually saved time should just remove the import. -jJ

2 1

Re: [Python-Dev] [regex] memory leak
by MRAB 02 Aug '09

02 Aug '09

John Machin wrote: > Hi Matthew, > > Your post in c.l.py about your re rewrite didn't mention where to report > bugs etc so I dug this address out of Google Groups ... > > Environment: Python 2.6.2, Windows XP SP3, your latest (29 July) regex > from the Python bugtracker. > > Problem is repeated calls of e.g. compiled_pattern.search(some_text) -- > Task Manager performance panel shows increasing memory usage with regex > but not with re. It appears to be cumulative i.e. changing to another > pattern or text doesn't release memory. > > Example: > > 8<-- regex_timer.py > import sys > import time > if sys.platform == 'win32': > timer = time.clock > else: > timer = time.time > module = __import__(sys.argv[1]) > count = int(sys.argv[2]) > pattern = sys.argv[3] > expected = sys.argv[4] > text = 80 * '~' + 'qwerty' > rx = module.compile(pattern) > t0 = timer() > for i in xrange(count): > assert rx.search(text).group(0) == expected > t1 = timer() > print "%d iterations in %.6f seconds" % (count, t1 - t0) > 8<--- > > Here are the results of running this (plus observed difference between > peak memory usage and base memory usage): > > dos-prompt>\python26\python regex_timer.py regex 1000000 "~" "~" > 1000000 iterations in 3.811500 seconds [60 Mb] > > dos-prompt>\python26\python regex_timer.py regex 2000000 "~" "~" > 2000000 iterations in 7.581335 seconds [128 Mb] > > dos-prompt>\python26\python regex_timer.py re 2000000 "~" "~" > 2000000 iterations in 2.549738 seconds [3 Mb] > > This happens on a variety of patterns: "w", "wert", "[a-z]+", "[a-z]+t", > ... > Thanks for that, John. I've should've kept an eye on the Task Manager! :-) Now fixed. It's surprising how much time and effort is needed just to manage the memory!

1 0

REVIEW: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
by Sean Reifschneider 01 Aug '09

01 Aug '09

Please review this, I'm worried that there are cases where convertitem() is returning a string that really should be overridden by the argument "help string". However, I'm worried that this change will get rid of useful messages (via the format "; help string"), when there otherwise wouldn't be. PyArg_ParseTuple when handling a string format "s", raises a TypeError when the passed string contains a NUL. However, the TypeError doesn't contain useful information. For example: syslog.syslog('hello\0there') TypeError: [priority,] message string This seems to be a thinko in Python/getargs.c at line 331: msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, flags, levels, msgbuf, sizeof(msgbuf), &freelist); if (msg) { seterror(i+1, msg, levels, fname, message); <<< Line 331 return cleanreturn(0, freelist); } This also applies to Python 3 trunk in line 390. I think that's supposed to be "msg" instead of "message" in the last argument. If I change it, I get: >>> import syslog; syslog.syslog('hello\0there') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: must be string without null bytes, not str I think it's safe to change "message" to "msg" because: "message" is the "help" string "[priority,] message string", but "msg" contains much more useful information. "msg" is in the "fall back if the last argument doesn't contain useful information" argument position, but "msg" is never NULL. "message" only is NULL if the format string doesn't contain ";". In every case I can find in the code, convertitem() is returning a much more useful string than the help string. Or perhaps it should do something like: if (msg) { seterror(i+1, msg, levels, fname, '%s (%s)' % ( msg, message )); Pardon my mixed C+Python, but you get the idea. Thoughts? Thanks, Sean -- [...] Premature optimization is the root of all evil. -- Donald Knuth Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

2 2