Mailman 3 August 2011 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
by Éric Araujo Sept. 5, 2011

Sept. 5, 2011

Hi, However small the commit was, I think it still was a feature request, so I wonder if it was appropriate for the stable versions. Regards

5 6

Python 3 optimizations continued...
by stefan brunthaler Sept. 2, 2011

Sept. 2, 2011

Hi, pretty much a year ago I wrote about the optimizations I did for my PhD thesis that target the Python 3 series interpreters. While I got some replies, the discussion never really picked up and no final explicit conclusion was reached. AFAICT, because of the following two factors, my optimizations were not that interesting for inclusion with the distribution at that time: a) Unladden Swallow was targeting Python 3, too. b) My prototype did not pass the regression tests. As of November 2010 (IIRC), Google is not supporting work on US anymore, and the project is stalled. (If I am wrong and there is still activity and any plans with the corresponding PEP, please let me know.) Which is why I recently spent some time fixing issues so that I can run the regression tests. There is still some work to be done, but by and large it should be possible to complete all regression tests in reasonable time (with the actual infrastructure in place, enabling optimizations later on is not a problem at all, too.) So, the two big issues aside, is there any interest in incorporating these optimizations in Python 3? Have a nice day, --stefan PS: It probably is unusual, but in a part of my home page I have created a link to indicate interest (makes both counting and voting easier, http://www.ics.uci.edu/~sbruntha/) There were also links indicating interest in funding the work; I have disabled these, so as not to upset anybody or make the impression of begging for money...

20 70

Software Transactional Memory for Python
by Armin Rigo Aug. 31, 2011

Aug. 31, 2011

Hi all, About multithreading models: I recently made an observation which might be obvious to some, but not to me, and as far as I know not to most of us either. I think that it's worth being pointed out :-) http://mail.python.org/pipermail/pypy-dev/2011-August/008153.html A bientôt, Armin.

7 13

Coding guidelines for os.walk filter
by Jacek Pliszka Aug. 31, 2011

Aug. 31, 2011

Hi! I would like to get some opinion on possible os.walk improvement. For the sake of simplicity let's assume I would like to skip all .svn and tmp directories. Current solution looks like this: for t in os.walk(somedir): t[1][:]=set(t[1])-{'.svn','tmp'} ... do something This is a very clever hack but... it relies on internal implementation of os.walk.... Alternative is adding os.walk parameter e.g. like this: def walk(top, topdown=True, onerror=None, followlinks=False, walkfilter=None) .... if walkfilter is not None: dirs,nondirs=walkfilter(top,dirs,nondirs) ..... and remove .svn and tmp in the walkfilter definition. What I do not like here is that followlinks is redundant - easily implementable through walkfilter Simpler but braking backward-compatibility option would be: def walk(top, topdown=True, onerror=None, skipdirs=islink) ... - if followlinks or not islink(new_path): - for x in walk(new_path, topdown, onerror, followlinks): + if not skipdirs(new_path): + for x in walk(new_path, topdown, onerror, skipdirs): And user given skipdirs function should return true for new_path ending in .svn or tmp Nothing is redundant and works fine with topdown=False! What do you think? Shall we: a) do nothing and use the implicit hack b) make the option explicit with backward compatibility but with redundancy and topdown=False incompatibility c) make the option explicit braking backward compatibility but no redundancy Best Regards, Jacek Pliszka

2 1

PyPI went down
by Oleg Broytman Aug. 30, 2011

Aug. 30, 2011

Hello! I released the first package of two and PyPI went down while I was preparing to release the second. I hope it wasn't me? Oleg. -- Oleg Broytman http://phdru.name/ phd(a)phdru.name Programmers don't die, they just GOSUB without RETURN.

3 5

Re: [Python-Dev] cpython: Remove display options (--name, etc.) from the Distribution class.
by Antoine Pitrou Aug. 30, 2011

Aug. 30, 2011

On Tue, 30 Aug 2011 16:22:14 +0200 eric.araujo <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/af0bcccb935b > changeset: 72127:af0bcccb935b > user: Éric Araujo <merwok(a)netwok.org> > date: Tue Aug 30 00:55:02 2011 +0200 > summary: > Remove display options (--name, etc.) from the Distribution class. > > These options were used to implement “setup.py --name”, > “setup.py --version”, etc. which are now handled by the pysetup metadata > action or direct parsing of the setup.cfg file. > > As a side effect, the Distribution class no longer accepts a 'url' key > in its *attrs* argument: it has to be 'home-page' to be recognized as a > valid metadata field and passed down to the dist.metadata object. I don't want to sound nitpicky, but it's the first time I see "home-page" hyphenized. How about "homepage"? Regards Antoine.

2 1

PEP 393 review
by "Martin v. Löwis" Aug. 30, 2011

Aug. 30, 2011

Guido has agreed to eventually pronounce on PEP 393. Before that can happen, I'd like to collect feedback on it. There have been a number of voice supporting the PEP in principle, so I'm now interested in comments in the following areas: - principle objection. I'll list them in the PEP. - issues to be considered (unclarities, bugs, limitations, ...) - conditions you would like to pose on the implementation before acceptance. I'll see which of these can be resolved, and list the ones that remain open. Regards, Martin

8 42

Planned PEP status changes
by Nick Coghlan Aug. 30, 2011

Aug. 30, 2011

Unless I hear any objections, I plan to adjust the current PEP statuses as follows some time this weekend: Move from Accepted to Finished: 389 argparse - New Command Line Parsing Module Bethard 391 Dictionary-Based Configuration For Logging Sajip 3108 Standard Library Reorganization Cannon 3135 New Super Spealman, Delaney, Ryan Move from Accepted to Withdrawn (with a reference to Reid Kleckner's blog post) 3146 Merging Unladen Swallow into CPython Winter, Yasskin, Kleckner The PEP 3118 enhanced buffer protocol has some ongoing semantic and implementation issues still to be worked out, so I plan to leave that at Accepted. Ditto for PEP 3121 (extension module finalisation), since that doesn't play nicely with the current 'set everything to None' approach to breaking cycles during module finalisation. The other Accepted PEPs are either packaging standards related or genuinely not implemented yet. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

issue 6721 "Locks in python standard library should be sanitized on fork"
by Nir Aides Aug. 30, 2011

Aug. 30, 2011

Hi all, Please consider this invitation to stick your head into an interesting problem: http://bugs.python.org/issue6721 Nir

8 18

PEP 3151 from the BDFOP
by Barry Warsaw Aug. 29, 2011

Aug. 29, 2011

I am sending this review as the BDFOP for PEP 3151. I've read the PEP and reviewed the python-dev discussion via Gmane. I have not reviewed the hg branch where Antoine has implemented it. I'm not quite ready to pronounce, but I do have some questions and comments. First off, thanks to Antoine for taking this issue on, and for his well written and well reasoned PEP. There's definitely a problem here and I think Python will be better off for having addressed it. I, for one, will be very happy when I can eliminate the majority of `import errno`s from my code. ;) One guiding principle for me is that we should keep the abstraction as thin as possible. In particular, I'm concerned about mapping multiple errnos into a single Error. For example both EPIPE and ESHUTDOWN mapping to BrokePipeError, or EACESS or EPERM to PermissionError. I think we should resist this, so that one errno maps to exactly one Error. Where grouping is desired, Python already has mechanisms to deal with that, e.g. superclasses and multiple inheritance. Therefore, I think it would be better to have + FileSystemPermissionError + AccessError (EACCES) + PermissionError (EPERM) Yes, it makes the hierarchy deeper, and means you have to come up with a few more names, but I think it will also make it easier for the programmer to use and debug. Also, some of the artificial hierarchy introduced in the PEP may not be necessary (e.g. the faux superclass FileSystemPermissionError above). This might lead to the elimination of FileSystemError as some have suggested (I too question its utility). Similarly, I think it would be helpful to have the errno name (e.g. ENOENT) in the error message string. That way, it won't get in the way for most code, but would be usefully printed out for uncaught exceptions. A second guiding principle should be that careful code that works in Python 3.2 must continue to work in Python 3.3 once PEP 3151 is accepted, but also for Python 2 code ported straight to Python 3.3. Given the PEP's emphasis on "useful compatibility", I think this will be the case. Do be prepared for complaints about compatibility for careless code though - there's a ton of that out in the wild, and people will always complain with their "working" code breaks due to an upgrade. Be *very* explicit about this in the release notes and NEWS file, and put your asbestos underoos on. On the plus side, there's not so much Python 3 code to break :). Also, do clearly explain any required migration strategy for existing code, probably in this PEP. Have you considered the impact of this PEP on other Python implementations? My hazy memory of Jython tells me that errnos don't really leak into Java and thus Jython much, but what about PyPy and IronPython? E.g. step 1's deprecation strategy seems pretty CPython-centric. As for step 1 (coalescing the errors). This makes sense and I'm generally agreeable, but I'm wondering whether it's best to re-use IOError for this rather than introduce a new exception. Not that I can think of a good name for that. I'm just not totally convinced that existing code when upgrading to Python 3.3 won't introduce silent failures. If an existing error is to be re-used for this, I'm torn on whether IOError or OSError is a better choice. Popularity aside, OSError *feels* more right. What is the impact of the PEP on tools such as 2to3 and 3to2? Just to be clear, am I right that (on POSIX systems at least) IOError and its subclasses will always have an errno attribute still? And that anything raising an exception (e.g. via PyErr_SetFromErrno) other than the new ones will raise IOError? I also think that rather than transforming exception when raised from Python, i.e. via __new__ hackery, perhaps it should be a ValueError in its own right to raise IOError with an error represented by one of the subclasses. Chained exceptions would mean that the original exception needn't get lost. I surveyed some of my own code and observed (as others have) that EISDIR and ENOTDIR are pretty rare. I found more examples of ECHILD and ESRCH than the former two. How'd you like to add those two to make your BDFOP happy? :) What follows are some crazier ideas. I'm just throwing them out there, not necessarily suggesting they should go into the PEP. The new syntax (e.g. if clause on except) is certainly appealing at first glance, and might be of more general use for Python, but I agree with the problems as stated in the PEP. However, there might be a few things that *can* be done to make even the uncommon cases easier. E.g. What if all the errno symbolic names were mapped as attributes on IOError? The only advantage of that would be to eliminate the need to import errno, or for the ugly `e.errno == errno.ENOENT` stuff. That would then be rewritten as `e.errno == IOError.ENOENT`. A mild savings to be sure, but still. How dumb/useless/unworkable would it be to add an __future__ to switch from the old hierarchy to the new one? Probably pretty. ;) What about an api that applications/libraries could use to add additional exceptions based on other errnos they cared about? This could be consulted in PyErr_SetFromErrno() and raised instead of IOError. Okay, yeah, that's probably pretty dumb too. Anyway, that's all I have. I certainly feel like this PEP is pretty close to being accepted. Good work! -Barry

3 6