Mailman 3 June 2011 - Python-Dev

Fwd: [Python-committers] Pulling from contributors repositories
by Hirokazu Yamamoto 15 Jun '11

15 Jun '11

I've read the Python-committers thread "Pulling from contributors repositories", which is about version control system. It seems there are two main issues, linear (cleaner) history on pushing, and NEWS merging. I'm newby of bazaar, but it seems to have a solution for first issue. $ bzr checkout /repo/trunk $ bzr merge /repo/feature-a $ bzr revert --forget-merges $ bzr push See http://doc.bazaar.canonical.com/latest/en/user-guide/adv_merging.html#mergi…

2 1

packaging was not getting installed
by Barry Warsaw 14 Jun '11

14 Jun '11

I just fixed Makefile.pre.in to install the packaging directory and all its subdirs. Without this `python3.3 -c 'import packaging'` fails from the installation target directory. I'm not sure the Fellowship intends for every subdir to get installed, so please double check. I just added everything that came from `find Lib/packaging -type d`. Cheers, -Barry

2 1

Pathscale compilers open source
by Skip Montanaro 14 Jun '11

14 Jun '11

One of my colleagues with a background in the high performance computing realm sent me this press release: http://www.pathscale.com/ekopath4-open-source-announcement I'm not personally familiar with the Pathscale compilers, but thought some folks here might be and might want to experiment with them. Skip

2 1

Re: [Python-Dev] Python 3.x and bytes
by P.J. Eby 14 Jun '11

14 Jun '11

At 01:56 AM 6/14/2011 +0000, exarkun(a)twistedmatrix.com wrote: >On 12:35 am, ncoghlan(a)gmail.com wrote: >>On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby <pje(a)telecommunity.com> wrote: >>>You can still do it one at a time: >>> >>>CHAR, = b'C' >>>INT, = b'I' >>>... >>> >>>etc. I just tried it with Python 3.1 and it works there. >> >>I almost mentioned that, although it does violate one of the >>"unwritten rules of the Zen" (in this case, "syntax shall not look >>like grit on Tim's monitor") > > [CHAR] = b'C' > [INT] = b'I' > ... Holy carpal tunnel time machine... That works in 2.3. (Without the 'b' of course.) Didn't know you could just use list syntax like that. It's an extra character to type, and two more shift keyings, but brevity isn't always the soul of clarity.

3 2

Call For Topics for Python Language Summit at EuroPython 2011
by Larry Hastings 14 Jun '11

14 Jun '11

Howdy howdy. Michael Foord can't make it to EuroPython this year--and congratulations to him on his new baby!--so he's asked me to chair the Python Language Summit in his stead. Although I have some suggested topics from Michael, I don't have any burning issues of my own to add to the docket. That's where *you* come in. If you have a topic you'd like to suggest, please email it privately to me (larry at hastings dot org) along with an estimate of how long you think it'll take to discuss. Please have all suggestions to me no later than Friday June 17th. Also, please include the phrase "Python Language Summit" in the subject line, in case it gets caught in my spam filters. You don't have to be attending the summit to suggest a topic--I'll consider suggestions from anybody. Hope to see you at EuroPython, /larry/

1 0

Python 3.x and bytes
by Ethan Furman 14 Jun '11

14 Jun '11

The bytes type in Python 3 does not feel very consistent. For example: --> some_var = 'abcdef' --> some_var 'abcdef' --> some_var[3] 'd' --> some_other_var = b'abcdef' --> some_other_var b'abcdef' --> some_other_var[3] 100 On the one hand we have the 'bytes are ascii data' type interface, and on the other we have the 'bytes are a list of integers between 0 - 256' interface. And trying to use the two is not intuitive: --> some_other_var[3] == b'd' False When I'm parsing a .dbf file and extracting field types from the byte stream, I'm not thinking, "okay, 67 is a Character field" -- what I'm thinking is, "b'C' is a Character field". Considering that ord() still works fine, I'm not sure why it was done this way. Is there code out there that is using this "list of int's" interface, or is there time to make changes to bytes? ~Ethan~

25 64

is anyone using Misc/RPM?
by Benjamin Peterson 13 Jun '11

13 Jun '11

If no one is using it, I'd like to delete it. I also don't think we should be in business of distributing distribution specific files. -- Regards, Benjamin

5 7

Participation Requested: Survey about Open-Source Software Development
by Jeffrey Carver 13 Jun '11

13 Jun '11

Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 19 years of age to complete the survey. The survey should take approximately 15 minutes to complete. If you are actively participating as a developer, please consider completing our survey. Here is the link to the survey: http://goo.gl/HQnux We apologize for inconvenience and if you receive multiple copies of this email. This survey has been approved by The University of Alabama IRB board. Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver

1 0

Implement Aspect-oriented programming
by Jiawei Li 13 Jun '11

13 Jun '11

For example, the logging module is not very useful right now, as it requires sprinkling small one-liners all over my code - not exactly ideal. Why not take a page from aspect-oriented programming and allow for injection of code with point cuts?

4 3

[RELEASED] Python 3.1.4
by Benjamin Peterson 12 Jun '11

12 Jun '11

On behalf of the Python development team, I'm sanguine to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. Since the 3.1.4 release candidate 2 weeks ago, there have been three changes: 1. test_zipfile has been fixed on systems with an ASCII filesystem encoding. 2. pyexpat.__version__ has be changed to be the Python version. 3. A regression from 2.7.1 in the handling of comments in the netrc module has been resolved. (see issue #12009). 3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4, 3.1 will be in security-only fix mode. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a production release. To download Python 3.1.4 visit: http://www.python.org/download/releases/3.1.4/ A list of changes in 3.1.4 can be found here: http://hg.python.org/cpython/raw-file/feae9f9e9f30/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy and be merry! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.4's contributors)

2 2

[RELEASE] Python 2.7.2
by Benjamin Peterson 12 Jun '11

12 Jun '11

On behalf of the Python development team, I'm rosy to announce the immediate availability of Python 2.7.2. Since the release candidate 2 weeks ago, there have been 2 changes: 1. pyexpat.__version__ has be changed to be the Python version. 2. A regression from 3.1.3 in the handling of comments in the netrc module has been resolved. (see issue #12009). 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last major verison of the 2.x line and will be receiving only bug fixes while new feature development focuses on 3.x. The 2.7 series includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.2 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.2 changelog is at: http://hg.python.org/cpython/raw-file/eb3c9b74884c/Misc/NEWS 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy and for those in the northern hemisphere, have a nice summer! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7.2's contributors)

2 1

Re: [Python-Dev] [Python-checkins] cpython (2.7): allow "fake" filenames in findsource (closes #9284)
by Nick Coghlan 12 Jun '11

12 Jun '11

On Sun, Jun 12, 2011 at 6:56 AM, benjamin.peterson <python-checkins(a)python.org> wrote: > summary: > allow "fake" filenames in findsource (closes #9284) > > This allows findsource() to work in doctests. > > A patch from Dirkjan Ochtman. Either this exception should be mentioned in the inspect.getsource() documentation or else doctest should be monkeypatching inspect as well as linecache. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

Re: [Python-Dev] [Python-checkins] cpython (3.1): onto 3.1.5
by Benjamin Peterson 11 Jun '11

11 Jun '11

2011/6/11 Terry Reedy <tjreedy(a)udel.edu>: > >> +What's New in Python 3.1.5? >> +=========================== >> + >> +*Release date: XXXX-XX-XX* >> + >> +Core and Builtins >> +----------------- >> + >> +Library >> +------- >> + >> + > > I presume that only security patches should be added. Indeed. -- Regards, Benjamin

1 0

Python jails
by Sam Edwards 11 Jun '11

11 Jun '11

Hello! This is my first posting to the python-dev list, so please forgive me if I violate any unspoken etiquette here. :) I was looking at Python 2.x's f_restricted frame flag (or, rather, the numerous ways around it) and noticed that most (all?) of the attacks to escape restricted execution involved the attacker grabbing something he wasn't supposed to have. IMO, Python's extensive introspection features make that a losing battle, since it's simply too easy to forget to blacklist something and the attacker finding it. Not only that, even with a perfect vacuum-sealed jail, an attacker can still bring down the interpreter by exhausting memory or consuming excess CPU. I think I might have a way of securely sealing-in untrusted code. It's a fairly nascent idea, though, and I haven't worked out all of the details yet, so I'm posting what I have so far for feedback and for others to try to poke holes in it. Absolutely nothing here is final. I'm just framing out what I generally had in mind. Obviously, it will need to be adjusted to be consistent with "the Python way" - my hope is that this can become a PEP. :) >>> # It all starts with the introduction of a new type, called a jail. (I haven't yet worked out whether it should be a builtin type, ... # or a module.) Unjailed code can create jails, which will run the untrusted code and keep strict limits on it. ... >>> j = jail() >>> dir(j) ['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'acquire', 'getcpulimit', 'getcpuusage', 'getmemorylimit', 'getmemoryusage', 'gettimelimit', 'gettimeusage', 'release', 'setcpulimit', 'setmemorylimit', 'settimelimit'] >>> # The jail monitors three things: Memory (in bytes), real time (in seconds), and CPU time (also in seconds) ... # and it also allows you to impose limits on them. If any limit is non-zero, code in that jail may not exceed its limit. ... # Exceeding a memory limit will result in a MemoryError. I haven't decided what CPU/real time limits should raise. ... # The other two calls are "acquire" and "release," which allow you to seal (any) objects inside the jail, or bust them # out. Objects inside the jail (i.e. created by code in that jail) contribute their __sizeof__() to the j.getmemoryusage() ... >>> def stealPasswd(): ... return open('/etc/passwd','r').read() ... >>> j.acquire(stealPasswd) >>> j.getmemoryusage() # The stealPasswd function, its code, etc. are now locked away within the jail. 375 >>> stealPasswd() Traceback (most recent call last): File "<stdin>", line 1, in <module> JailError: tried to access an object outside of the jail The object in question is, of course, 'open'. Unlike the f_restricted model, the jail was freely able to grab the open() function, but was absolutely unable to touch it: It can't call it, set/get/delete attributes/items, or pass it as an argument to any functions. There are three criteria that determine whether an object can be accessed: a. The code accessing the object is not within a jail; or b. The object belongs to the same jail as the code accessing the object; or c. The object has an __access__ function, and theObject.__access__(theJail) returns True. For the jail to be able to access 'open', it needs to be given access explicitly. I haven't quite decided how this should work, but I had in mind the creation of a "guard" (essentially a proxy) that allows the jail to access the object. It belongs to the same jail as the guarded object (and is therefore impossible to create within a jail unless the guarded object belongs to the same jail), has a list of jails (or None for 'any') that the guard will allow to __access__ it (the guard is immutable, so jails can't mess with it even though they can access it), and what the guard will allow though it (read-write, read-only, call-within-jail, call-outside-jail). I have a couple remaining issues that I haven't quite sussed out: * How exactly do guards work? I had in mind a system of proxies (memory usage is a concern, especially in memory-limited jails - maybe allow __access__ to return specific modes of access rather than all-or-nothing?) that recursively return more guards after operations. (e.g., if I have a guard allowing read+call on sys, sys.stdout would return another guard allowing read+call on sys.stdout, likewise for sys.stdout.write) * How are objects sealed in the jail? j.acquire can lead to serious problems with lots of references getting recursively sealed in. Maybe disallow sealing in anything but code objects, or allow explicitly running code within a jail like j.execute(code, globals(), locals()), which works fine since any objects created by jailed code are also jailed. * How do imports work? Should __import__ be modified so that when a jail invokes it, the import runs normally (unjailed), and then returns the module with a special guard that allows read-only+call-within, but not on builtins? This has a nice advantage, since jailed code can import e.g. socket, and maybe even create a socket, but won't be able to do sock.connect(...), since socket.connect (which is running with jailed permissions) can't touch the builtin _socket module. * Is obj.__access__(j) the best way to decide access? It doesn't allow programmers much freedom to customize the jail policy since they can't modify __access__ for builtins. Maybe the jail should have the first chance (such as j.__access__(obj)), which allows programmers to subclass the jail, and the jail can fallback to obj.__access__(j) * How does Python keep track of what jail each frame is in? Maybe each frame can have a frame.f_jail, which references the jail object restricting that frame (or None for unjailed code) - frames' jails default to the jail holding the code object, or can be explicitly overridden (as in j.execute(code, globals(), locals())) * When are jails switched? Obviously, jailed code called from unjailed code (or even from other unjailed code) should be executed in the callee jail... But if a jailed caller is calling unjailed code, does the jail follow, or does the unjailed code run in an unjailed frame? How do programmers specify that? ...that's pretty much my two (erm, twenty) cents on the matter. Again, any feedback/adversarial reasoning you guys can offer is much appreciated.

5 5

Re: [Python-Dev] cpython: Remove some extraneous parentheses and swap the comparison order to
by Georg Brandl 10 Jun '11

10 Jun '11

On 06/07/11 05:20, brett.cannon wrote: > http://hg.python.org/cpython/rev/fc282e375703 > changeset: 70695:fc282e375703 > user: Brett Cannon <brett(a)python.org> > date: Mon Jun 06 20:20:36 2011 -0700 > summary: > Remove some extraneous parentheses and swap the comparison order to > prevent accidental assignment. > > Silences a warning from LLVM/clang 2.9. Swapping the comparison order here seems a bit inconsistent to me. There are lots of others around (e.g. "len == 0" in the patch context below). Why is this one so special? I think that another developer even got told off once for these kinds of comparisons. I hope the Clang warning is only about the parentheses. Georg > files: > Modules/arraymodule.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/Modules/arraymodule.c b/Modules/arraymodule.c > --- a/Modules/arraymodule.c > +++ b/Modules/arraymodule.c > @@ -2091,7 +2091,7 @@ > if (len == 0) { > return PyUnicode_FromFormat("array('%c')", (int)typecode); > } > - if ((typecode == 'u')) > + if ('u' == typecode) > v = array_tounicode(a, NULL); > else > v = array_tolist(a, NULL);

12 14

Summary of Python tracker Issues
by Python tracker 10 Jun '11

10 Jun '11

ACTIVITY SUMMARY (2011-06-03 - 2011-06-10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2826 (+11) closed 21268 (+47) total 24094 (+58) Open issues with patches: 1236 Issues opened (45) ================== #5906: Risk of confusion in multiprocessing module - daemonic process http://bugs.python.org/issue5906 reopened by pakal #9516: sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but http://bugs.python.org/issue9516 reopened by eric.araujo #12255: A few changes to .*ignore http://bugs.python.org/issue12255 opened by eric.araujo #12256: Link isinstance/issubclass doc to abc module http://bugs.python.org/issue12256 opened by eric.araujo #12257: Rework/replace use of DISTUTILS_USE_SDK in packaging http://bugs.python.org/issue12257 opened by eric.araujo #12258: Clean up bytes I/O in get_compiler_versions http://bugs.python.org/issue12258 opened by eric.araujo #12259: Test and document which compilers can be created on which plat http://bugs.python.org/issue12259 opened by eric.araujo #12260: Make install default to user site-packages http://bugs.python.org/issue12260 opened by eric.araujo #12261: urllib.parse docs still refer to urlparse http://bugs.python.org/issue12261 opened by tlesher #12263: punycode codec ignores the error handler argument http://bugs.python.org/issue12263 opened by haypo #12268: file readline, readlines & readall methods can lose data on EI http://bugs.python.org/issue12268 opened by gregory.p.smith #12271: Python 2.7.x on IA64 running SLES 11 SP1 http://bugs.python.org/issue12271 opened by v.claudic #12272: Python 2.7.1 version conflict for package "Tcl" on Windows 7 http://bugs.python.org/issue12272 opened by jackie3 #12273: Change ast.__version__ calculation to provide consistent order http://bugs.python.org/issue12273 opened by ncoghlan #12274: "Print window" menu on IDLE aborts whole application http://bugs.python.org/issue12274 opened by gagenellina #12275: urllib.request.HTTPRedirectHandler won't redirect to a URL wit http://bugs.python.org/issue12275 opened by lilydjwg #12276: 3.x ignores sys.tracebacklimit=0 http://bugs.python.org/issue12276 opened by gagenellina #12277: Missing comma in os.walk docs http://bugs.python.org/issue12277 opened by Retro #12278: Core mentorship mention in the devguide http://bugs.python.org/issue12278 opened by adam.woodbeck #12279: Add build_distinfo command to packaging http://bugs.python.org/issue12279 opened by eric.araujo #12281: bytes.decode('mbcs', 'ignore') does replace undecodable bytes http://bugs.python.org/issue12281 opened by haypo #12282: build process adds CWD (null entry) to PYTHONPATH if PYTHONPAT http://bugs.python.org/issue12282 opened by r.david.murray #12284: argparse.ArgumentParser: usage example option http://bugs.python.org/issue12284 opened by jonash #12285: Unexpected behavior for 0 or negative processes in multiproces http://bugs.python.org/issue12285 opened by jorgsk #12287: ossaudiodev: stack corruption with FD >= FD_SETSIZE http://bugs.python.org/issue12287 opened by neologix #12288: Python 2.7.1 tkSimpleDialog initialvalue http://bugs.python.org/issue12288 opened by busfault #12289: http.server.CGIHTTPRequestHandler doesn't check if a Python sc http://bugs.python.org/issue12289 opened by haypo #12290: __setstate__ is called for false values http://bugs.python.org/issue12290 opened by eltoder #12291: file written using marshal in 3.2 can be read by 2.7, but not http://bugs.python.org/issue12291 opened by vinay.sajip #12294: multiprocessing.Pool: Need a way to find out if work are finis http://bugs.python.org/issue12294 opened by mozbugbox #12295: Fix ResourceWarning in turtledemo help window http://bugs.python.org/issue12295 opened by eric.araujo #12296: Minor clarification in devguide http://bugs.python.org/issue12296 opened by eric.araujo #12297: Clarifications to atexit.register and unregister doc http://bugs.python.org/issue12297 opened by eric.araujo #12299: Stop documenting functions added by site as builtins http://bugs.python.org/issue12299 opened by eric.araujo #12300: Document pydoc.help http://bugs.python.org/issue12300 opened by eric.araujo #12301: Use :data:`sys.thing` instead of ``sys.thing`` throughout http://bugs.python.org/issue12301 opened by eric.araujo #12302: packaging test command needs access to .dist-info http://bugs.python.org/issue12302 opened by michael.mulich #12303: expose sigwaitinfo() and sigtimedwait() in the signal module http://bugs.python.org/issue12303 opened by haypo #12304: expose signalfd(2) in the signal module http://bugs.python.org/issue12304 opened by haypo #12305: Building PEPs doesn't work on Python 3 http://bugs.python.org/issue12305 opened by ericsnow #12306: zlib: Expose zlibVersion to query runtime version of zlib http://bugs.python.org/issue12306 opened by torsten #12307: Inconsistent formatting of section titles in PEP 0 http://bugs.python.org/issue12307 opened by ericsnow #12308: Add link to PEP 0 for topical index in wiki http://bugs.python.org/issue12308 opened by ericsnow #12309: os.environ was modified by test_packaging http://bugs.python.org/issue12309 opened by haypo #12310: Segfault in test_multiprocessing http://bugs.python.org/issue12310 opened by haypo Most recent 15 issues with no replies (15) ========================================== #12309: os.environ was modified by test_packaging http://bugs.python.org/issue12309 #12308: Add link to PEP 0 for topical index in wiki http://bugs.python.org/issue12308 #12307: Inconsistent formatting of section titles in PEP 0 http://bugs.python.org/issue12307 #12306: zlib: Expose zlibVersion to query runtime version of zlib http://bugs.python.org/issue12306 #12305: Building PEPs doesn't work on Python 3 http://bugs.python.org/issue12305 #12303: expose sigwaitinfo() and sigtimedwait() in the signal module http://bugs.python.org/issue12303 #12301: Use :data:`sys.thing` instead of ``sys.thing`` throughout http://bugs.python.org/issue12301 #12300: Document pydoc.help http://bugs.python.org/issue12300 #12299: Stop documenting functions added by site as builtins http://bugs.python.org/issue12299 #12297: Clarifications to atexit.register and unregister doc http://bugs.python.org/issue12297 #12296: Minor clarification in devguide http://bugs.python.org/issue12296 #12295: Fix ResourceWarning in turtledemo help window http://bugs.python.org/issue12295 #12294: multiprocessing.Pool: Need a way to find out if work are finis http://bugs.python.org/issue12294 #12288: Python 2.7.1 tkSimpleDialog initialvalue http://bugs.python.org/issue12288 #12272: Python 2.7.1 version conflict for package "Tcl" on Windows 7 http://bugs.python.org/issue12272 Most recent 15 issues waiting for review (15) ============================================= #12308: Add link to PEP 0 for topical index in wiki http://bugs.python.org/issue12308 #12306: zlib: Expose zlibVersion to query runtime version of zlib http://bugs.python.org/issue12306 #12304: expose signalfd(2) in the signal module http://bugs.python.org/issue12304 #12297: Clarifications to atexit.register and unregister doc http://bugs.python.org/issue12297 #12296: Minor clarification in devguide http://bugs.python.org/issue12296 #12295: Fix ResourceWarning in turtledemo help window http://bugs.python.org/issue12295 #12291: file written using marshal in 3.2 can be read by 2.7, but not http://bugs.python.org/issue12291 #12289: http.server.CGIHTTPRequestHandler doesn't check if a Python sc http://bugs.python.org/issue12289 #12287: ossaudiodev: stack corruption with FD >= FD_SETSIZE http://bugs.python.org/issue12287 #12285: Unexpected behavior for 0 or negative processes in multiproces http://bugs.python.org/issue12285 #12281: bytes.decode('mbcs', 'ignore') does replace undecodable bytes http://bugs.python.org/issue12281 #12278: Core mentorship mention in the devguide http://bugs.python.org/issue12278 #12277: Missing comma in os.walk docs http://bugs.python.org/issue12277 #12268: file readline, readlines & readall methods can lose data on EI http://bugs.python.org/issue12268 #12261: urllib.parse docs still refer to urlparse http://bugs.python.org/issue12261 Top 10 most discussed issues (10) ================================= #12248: __dir__ semantics changed in Python 2.7.2 http://bugs.python.org/issue12248 18 msgs #12014: str.format parses replacement field incorrectly http://bugs.python.org/issue12014 12 msgs #12246: Warn when trying to install third-party module from an uninsta http://bugs.python.org/issue12246 12 msgs #8927: Handle version incompatibilities in dependencies http://bugs.python.org/issue8927 11 msgs #12211: Better document math.copysign behavior. http://bugs.python.org/issue12211 11 msgs #12226: use secured channel for uploading packages to pypi http://bugs.python.org/issue12226 11 msgs #11457: Expose nanosecond precision from system calls http://bugs.python.org/issue11457 10 msgs #7511: msvc9compiler.py: ValueError when trying to compile with VC Ex http://bugs.python.org/issue7511 8 msgs #12084: os.stat() on windows doesn't consider relative symlink http://bugs.python.org/issue12084 8 msgs #12291: file written using marshal in 3.2 can be read by 2.7, but not http://bugs.python.org/issue12291 8 msgs Issues closed (47) ================== #3771: test_httpservers intermittent failure, test_post and EINTR http://bugs.python.org/issue3771 closed by gregory.p.smith #3992: remove custom log module from distutils2 http://bugs.python.org/issue3992 closed by eric.araujo #4949: Constness in PyErr_NewException http://bugs.python.org/issue4949 closed by benjamin.peterson #7015: Getting call trace while executing "modules spam" at help prom http://bugs.python.org/issue7015 closed by eric.araujo #8407: expose pthread_sigmask(), pthread_kill(), sigpending() and sig http://bugs.python.org/issue8407 closed by haypo #9205: Parent process hanging in multiprocessing if children terminat http://bugs.python.org/issue9205 closed by pitrou #9344: please add posix.getgrouplist() http://bugs.python.org/issue9344 closed by rosslagerwall #10027: os.lstat/os.stat don't set st_nlink on Windows http://bugs.python.org/issue10027 closed by brian.curtin #10424: better error message from argparse when positionals missing http://bugs.python.org/issue10424 closed by r.david.murray #10645: Remove egg-info files in stdlib http://bugs.python.org/issue10645 closed by eric.araujo #10694: zipfile.py end of central directory detection not robust http://bugs.python.org/issue10694 closed by r.david.murray #10884: pkgutil EggInfoDistribution requirements for .egg-info metadat http://bugs.python.org/issue10884 closed by michael.mulich #11028: Implement the setup.py -> setup.cfg in mkcfg http://bugs.python.org/issue11028 closed by eric.araujo #11041: On the distutils2 documentation, 'requires-python' shouldn't b http://bugs.python.org/issue11041 closed by eric.araujo #11092: setup.cfg isn't packaged when running sdist http://bugs.python.org/issue11092 closed by eric.araujo #11203: gzip doc is behind http://bugs.python.org/issue11203 closed by teamnoir #11583: os.path.isdir() is slow on windows http://bugs.python.org/issue11583 closed by brian.curtin #11893: Obsolete SSLFakeFile in smtplib? http://bugs.python.org/issue11893 closed by pitrou #12019: Dead or buggy code in importlib.test.__main__ http://bugs.python.org/issue12019 closed by eric.araujo #12021: mmap.read requires an argument http://bugs.python.org/issue12021 closed by neologix #12040: Expose a Process.sentinel property (and fix polling loop in Pr http://bugs.python.org/issue12040 closed by pitrou #12080: decimal.py: performance in _power_exact http://bugs.python.org/issue12080 closed by mark.dickinson #12127: Inconsistent leading zero treatment http://bugs.python.org/issue12127 closed by mark.dickinson #12168: SysLogHandler incorrectly appends \000 to messages http://bugs.python.org/issue12168 closed by vinay.sajip #12214: platform module can't detect archlinux distribution http://bugs.python.org/issue12214 closed by eric.araujo #12224: problem with siginterrupt http://bugs.python.org/issue12224 closed by haypo #12234: unittest2 could enable regex debugging for more information http://bugs.python.org/issue12234 closed by r.david.murray #12237: Document how to open non-default webbrowser http://bugs.python.org/issue12237 closed by terry.reedy #12249: add missing command http://bugs.python.org/issue12249 closed by eric.araujo #12254: PEP-3107 has a wrong attribute name for function annotations http://bugs.python.org/issue12254 closed by eric.araujo #12262: Not Inheriting File Descriptors on Windows? http://bugs.python.org/issue12262 closed by 3vi1 #12264: parser.expr(): reference count error if more than one argument http://bugs.python.org/issue12264 closed by python-dev #12265: revamp argument errors http://bugs.python.org/issue12265 closed by python-dev #12266: str.capitalize contradicts oneself http://bugs.python.org/issue12266 closed by r.david.murray #12267: Difficult to compile python in Visual Studio 2010 express http://bugs.python.org/issue12267 closed by loewis #12269: IDLE 2.7 hangs on Mac OS X 10.6 http://bugs.python.org/issue12269 closed by ned.deily #12270: Please update copyright notice on bugs.python.org to 2011? http://bugs.python.org/issue12270 closed by ezio.melotti #12280: If statement http://bugs.python.org/issue12280 closed by brian.curtin #12283: python3.2 smtplib _quote_periods http://bugs.python.org/issue12283 closed by r.david.murray #12286: float('nan') breaks sort() method on a list of floats http://bugs.python.org/issue12286 closed by ezio.melotti #12292: bpython http://bugs.python.org/issue12292 closed by amaury.forgeotdarc #12293: wrong arguments passed to SMTP.sendmail in example http://bugs.python.org/issue12293 closed by r.david.murray #12298: Sphinx glitch in library/functions http://bugs.python.org/issue12298 closed by georg.brandl #12311: memory leak with self-referencing dict http://bugs.python.org/issue12311 closed by Albert.Zeyer #12312: is ok http://bugs.python.org/issue12312 closed by brian.curtin #1083299: Distutils doesn't pick up all the files it should. http://bugs.python.org/issue1083299 closed by eric.araujo #1699259: replacing char* with const char* in sysmodule.c/.h http://bugs.python.org/issue1699259 closed by sebastinas

1 0

Re: [Python-Dev] cpython (3.2): Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat.
by Georg Brandl 09 Jun '11

09 Jun '11

On 06/09/11 02:00, brian.curtin wrote: > http://hg.python.org/cpython/rev/88e318166eaf > changeset: 70713:88e318166eaf > branch: 3.2 > parent: 70700:0aa3064d1cef > user: Brian Curtin <brian(a)python.org> > date: Wed Jun 08 18:17:18 2011 -0500 > summary: > Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat. > > By changing to the Windows GetFileAttributes API in nt._isdir we can figure > out if the path is a directory without opening the file via os.stat. This has > the minor benefit of speeding up os.path.isdir by at least 2x for regular > files and 10-15x improvements were seen on symbolic links (which opened the > file multiple times during os.stat). Since os.path.isdir is used in > several places on interpreter startup, we get a minor speedup in startup time. > > files: > Lib/ntpath.py | 13 ++++++++++ > Misc/NEWS | 3 ++ > Modules/posixmodule.c | 37 +++++++++++++++++++++++++++++++ > 3 files changed, 53 insertions(+), 0 deletions(-) > > > diff --git a/Lib/ntpath.py b/Lib/ntpath.py > --- a/Lib/ntpath.py > +++ b/Lib/ntpath.py > @@ -672,3 +672,16 @@ > def sameopenfile(f1, f2): > """Test whether two file objects reference the same file""" > return _getfileinformation(f1) == _getfileinformation(f2) > + > + > +try: > + # The genericpath.isdir implementation uses os.stat and checks the mode > + # attribute to tell whether or not the path is a directory. > + # This is overkill on Windows - just pass the path to GetFileAttributes > + # and check the attribute from there. > + from nt import _isdir > +except ImportError: > + from genericpath import isdir as _isdir > + > +def isdir(path): > + return _isdir(path) Not that it matters, but ISTM that this would be faster as try: from nt import _isdir as isdir except ImportError: pass Georg

3 2

3.2.1 and Issue 12291
by Vinay Sajip 09 Jun '11

09 Jun '11

I just filed an issue which shows a serious breakage in the marshal module: "file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3" http://bugs.python.org/issue12291 Perhaps this issue should be marked as a release blocker for 3.2.1 - what do others (particularly Georg, of course) think? While it does appear to have been broken for some time, it seems a bit too serious to leave until a 3.2.2 release. Regards, Vinay Sajip

2 1

Can we improve support for abstract base classes with desciptors
by Darren Dale 09 Jun '11

09 Jun '11

I would like to try to address some shortfalls with the way python deals with abstract base classes containing descriptors. I originally was just concerned with improving support for defining abstract properties with the decorator syntax and converting between abstract and concrete properties, but recently realized that the problem extends to descriptors in general. ABCs ---- First, a bit of background may be in order. An abstract base class is defined by specifying its metaclass as ABCMeta (or a subclass thereof):: class MyABC(metaclass=ABCMeta): @abstractmethod def foo(self): pass When trying to instantiate MyABC or any of its subclasses, ABCMeta inspects the current class namespace for items tagged with __isabstractmethod__=True:: class ABCMeta(type): #[...] def __new__(mcls, name, bases, namespace): cls = super().__new__(mcls, name, bases, namespace) # Compute set of abstract method names abstracts = {name for name, value in namespace.items() if getattr(value, "__isabstractmethod__", False)} ABCMeta then checks if any of the base classes define any items tagged with __isabstractmethod__ and whether they remain abstract in the current class namespace:: for base in bases: for name in getattr(base, "__abstractmethods__", set()): value = getattr(cls, name, None) if getattr(value, "__isabstractmethod__", False): abstracts.add(name) cls.__abstractmethods__ = frozenset(abstracts) In Objects/typeobject.c, __abstractmethods__ is actually a descriptor, and setting it gives the type a chance to set an internal flag specifying if it has any abstract methods defined. When object_new is called in typeobject.c, the flag is checked and an error is raised if any abstract methods were identified. Issues with ABCs and descriptors -------------------------------- In order for this scheme to work, ABCMeta needs to identify all of the abstract methods, but there are some limitations when we consider descriptors. For example, Python's property is a composite object, whose behavior is defined by the getter, setter, and deleter methods with which it is composed. Since there is already an @abstractmethod decorator, I would have suspected that defining abstract properties would be intuitive:: class MyABC(metaclass=ABCMeta): @abstractmethod def _get_foo(self): pass @abstractmethod def _set_foo(self, val): pass foo = property(_get_foo, _set_foo) @property @abstractmethod def bar(self): pass @bar.setter @abstractmethod def bar(self, val): pass Ideally, one would want the flexibility of defining a concrete getter and an abstract setter, for example. However, ABCMeta does not inspect the descriptors of a class to see if they contain any abstract methods. It only inspects the descriptor itself for a True __isabstractmethod__ attribute. This places the burdon on every descriptor implementation to provide its own support for ABC compatibility. For example, support for abstract properties was attempted by adding abstractproperty to the abc module. abstractproperty subclasses the property builtin (as opposed to the relationship between every other abstract and concrete class in the python language). Here is the definition of abstractproperty, in its entirety (modulo docstrings):: class abstractproperty(property): __isabstractmethod__ = True A number of problems manifest with this approach, and I think they all can be traced to the fact that the abstractedness of a descriptor is currently not dependent upon the abstractedness of the methods with which it is composed. The documentation for abstractproperty doesn't suggest using @abstractmethod:: class C(metaclass=ABCMeta): def getx(self): ... def setx(self, value): ... x = abstractproperty(getx, setx) which leads to Issue #1: What is abstract about C.x? How does a subclass of C know whether it needs to override the getter or setter? Issue #2: The decorator syntax cannot be used to convert an abstract property into a concrete one. (This relates to Issue #1: how would a descriptor even know when such a conversion would be appropriate?) Running the following code:: from abc import ABCMeta, abstractmethod, abstractproperty class AbstractFoo(metaclass=ABCMeta): @abstractproperty def bar(self): return 1 @bar.setter def bar(self, val): pass class ConcreteFoo(AbstractFoo): @AbstractFoo.bar.getter def bar(self): return 1 @bar.setter def bar(self, val): pass foo = ConcreteFoo() yields:: TypeError: Can't instantiate abstract class ConcreteFoo with abstract methods bar Issue #3: The following class *is* instantiable, even though AbstractFoo declared that a setter for bar is required:: class ConcreteFoo(AbstractFoo): @property def bar(self): pass Previous attempt to improve abc.abstractproperty ------------------------------------------------ It seems to me that the strategy used by abc.abstractproperty is fundamentally ill-advised. I explored the possibility of extending abstractproperty, redefining its getter, setter, and deleter methods such that they would work in conjunction with the @abstractmethod decorator and yield an instance of the builtin property once all abstract methods were replaced with concrete ones (http://bugs.python.org/issue11610). Issues #1 and #2 were addressed, but there were still problems with that approach. It did not address Issue #3, and it also introduced a new issue, #4:: class AbstractFoo(metaclass=ABCMeta): @abstractproperty # bar would be an abstractproperty, even though the getter is concrete def bar(self): return 1 @bar.setter # bar.setter inspected the getter and the new setter, did not identify # any abstract methods, and thus returned an instance of the built-in # property def bar(self, val): pass @bar.deleter # bar is a concrete property, its deleter decorator does not know it # is supposed to check for abstract methods, so it will return an # instance of the built-in property: @abstractmethod def bar(self): pass By the time the deleter was specified, bar was a concrete property, which does not know it should return an instance of abstractproperty (in part because the inheritance diagram for property/abstractproperty is inverted). Thus, AbstractFoo was instantiable, even though it shouldn't be. Finally, issue #5: the current approach taken by ABCMeta and abstractproperty places the burdon on descriptors to identify themselves to ABCMeta as abstract. Considering the issues encountered with abstractproperty, this may be an onerous requirement. There has been a fair amount of discussion at http://bugs.python.org/issue11610 , which can be summarized as a) concerns about maintaining backward compatibility, and b) objections to requiring @abstractmethod to specify that a method being passed to abstractproperty is abstract. Extending ABCMeta: A Promising Way Forward ------------------------------------------ I think the key is to focus on Issue #3. ABCMeta needs to be improved to recognize descriptor objects, both in the current namespace as well as the base classes, and to identify any abstract methods associated with the descriptors. I suggest the following approach in ABCMeta:: def __new__(mcls, name, bases, namespace): cls = super().__new__(mcls, name, bases, namespace) # Compute set of abstract method names def isdescriptor(val): return hasattr(val, '__get__') or hasattr(val, '__set__') \ or hasattr(val, '__delete__') def getabstracts(ns): return [name for name, value in ns.items() if getattr(value, "__isabstractmethod__", False)] abstracts = getabstracts(namespace) for item, val in namespace.items(): # further inspect descriptors for abstract methods: if isdescriptor(val): ## unfortunately, can't import inspect: #from inspect import getmembers #d = dict(getmembers(val)) ## so instead, use the following: d = dict((k, getattr(val, k, None)) for k in dir(val)) for name in getabstracts(d): # add the abstract descriptor methods to the list: abstracts.append('%s.%s'%(item, name)) for base in bases: for name in getattr(base, "__abstractmethods__", set()): if '.' in name: # base class identified a descriptor abstract method: k, v = name.split('.') desc = getattr(cls, k, None) val = getattr(desc, v, None) else: val = getattr(cls, name, None) if val is None or getattr(val, "__isabstractmethod__", False): abstracts.append(name) cls.__abstractmethods__ = frozenset(abstracts) I rolled everything into __new__ just to keep it as simple as possible for the sake of discussion. Python already provides the rest of the framework needed for descriptors to work properly with ABCs. This implementation actually works; I've tested it with an existing python-3.2 install:: from abc import ABCMeta, abstractmethod class AbstractFoo(metaclass=ABCMeta): @property @abstractmethod def bar(self): return 1 @bar.setter @abstractmethod def bar(self, val): pass >>> abstractfoo = AbstractFoo() Traceback (most recent call last): File "temp.py", line 17, in <module> abstractfoo = AbstractFoo() TypeError: Can't instantiate abstract class AbstractFoo with abstract methods bar.fget, bar.fset as expected. Note the more informative error message indicating what about the bar property is abstract. Also:: class ConcreteFoo(AbstractFoo): @AbstractFoo.bar.getter def bar(self): return 1 >>> foo = ConcreteFoo() Traceback (most recent call last): File "temp.py", line 24, in <module> foo = ConcreteFoo() TypeError: Can't instantiate abstract class ConcreteFoo with abstract methods bar.fset So issue #1 is addressed, since we are explicitly specifying which descriptor methods are abstract. Issue #2 has been addressed, since the following class is instantiable:: class ConcreteFoo(AbstractFoo): @AbstractFoo.bar.getter def bar(self): return 1 @bar.setter def bar(self, val): pass Issue #3 is also addressed. In the following example, even though I redefine the bar property as a readonly property, ABCMeta recognizes that a setter is needed:: class ConcreteFoo(AbstractFoo): @property def bar(self): return 1 >>> foo = ConcreteFoo() Traceback (most recent call last): File "temp.py", line 24, in <module> foo = ConcreteFoo() TypeError: Can't instantiate abstract class ConcreteFoo with abstract methods bar.fset Issue #4 (introduced in a previous attempt to solve the problem using abstractproperty) is also addressed:: class AbstractFoo(metaclass=ABCMeta): @property def bar(self): return 1 @bar.setter def bar(self, val): pass @bar.deleter @abstractmethod def bar(self): pass >>> abstractfoo = AbstractFoo() Traceback (most recent call last): File "temp.py", line 15, in <module> abstractfoo = AbstractFoo() TypeError: Can't instantiate abstract class AbstractFoo with abstract methods bar.fdel Finally, this approach addresses Issue #5 by holding ABCMeta responsible for identifying the abstractedness of descriptor methods, rather than placing that burdon on the desciptor objects to identify themselves as abstract. If ABCMeta were extended as above to identify abstract methods associated with descriptors, third parties would simply decorate methods used to compose the descriptors with @abstractmethod. This change to ABCMeta would not effect the behavior of abstractproperty, so backward compatibility would be maintained in that respect. But I think abstractproperty should be deprecated, or at the very least removed from the documentation. The documentation for @abstractmethod in >=python-3.3 should be extended to provide examples with properties/descriptors. The syntax would be backward compatible with older python versions, but with <python-3.3 ABCMeta would simply not recognize descriptors' abstract methods. This leads to one source of potential forward compatibility:: class AbstractFoo(metaclass=ABCMeta): @property @abstractmethod def bar(self): return 1 class ConcreteFoo(AbstractFoo): pass Both above classes would be instantiable with <python-3.3, but not with >=python3.3. In my opinion, this is a feature: python-3.3 has identified a bug in ConcreteFoo. The developer would not have tagged that method as abstract unless they had intended for consumers of AbstractFoo to provide a concrete implementation. Darren

2 5

The socket HOWTO
by Antoine Pitrou 09 Jun '11

09 Jun '11

Hello, I would like to suggest that we remove the socket HOWTO (currently at http://docs.python.org/dev/howto/sockets.html) My main issue with this document is that it doesn't seem to have a well-defined destination: - people who know sockets won't learn anything from it - but people who don't know sockets will probably find it clear as mud (for example, what's an "INET" or "STREAM" socket? what's "select"?) I have other issues, such as the style/tone it's written in. I'm sure the author had fun writing it but it doesn't fit well with the rest of the documentation. Also, the author gives a lot of "advice" without explaining or justifying it ("if somewhere in those input lists of sockets is one which has died a nasty death, the select will fail" -> is that really true? what is a "nasty death" and how is that supposed to happen? couldn't the author have put a 3-line example to demonstrate this supposed drawback and how it manifests?). And, finally, many statements seem arbitrary ("There’s no question that the fastest sockets code uses non-blocking sockets and select to multiplex them") or plain wrong ("threading support in Unixes varies both in API and quality. So the normal Unix solution is to fork a subprocess to deal with each connection"). I don't think giving misleading advice to users is really a good idea. And suggesting beginners they use non-blocking sockets without even *showing* how (or pointing to asyncore or Twisted) is a very bad idea. select() is not enough, you still have to be prepared to get EAGAIN or EWOULDBLOCK when calling recv() or send() (i.e. select() can give false positives). Oh and I think it's obsolete too, because the "class mysocket" concatenates the output of recv() with a str rather than a bytes object. Not to mention that features of the "class mysocket" can be had using a buffered socket.makefile() instead of writing custom code. (followed up from http://bugs.python.org/issue12126 at Eli's request) Regards Antoine.

17 35

fatal error callback issue
by Tom Whittock 09 Jun '11

09 Jun '11

I'm writing in regards to http://bugs.python.org/issue1195571 I'm embedding Python in my application and ran into a need for this functionality. I wrote a similar patch myself, and was about to submit it. When I searched for similar issues I found that this one has been available since 2005. I'd really like to help get this patch approved and integrated into the python sources. I'm sure many other python embedders have run into this in the past - it's a legitimate concern for any process which is not 100% hosted in the Python world. Thanks. Tom.

2 1

Re: [Python-Dev] [Python-checkins] cpython (2.7): Merge
by Victor Stinner 09 Jun '11

09 Jun '11

Le jeudi 09 juin 2011 à 02:30 +0200, brian.curtin a écrit : > http://hg.python.org/cpython/rev/f1509fc75435 > changeset: 70715:f1509fc75435 > branch: 2.7 > parent: 70661:6e7a98cfcfab > user: Brian Curtin <brian(a)python.org> > date: Wed Jun 08 19:29:53 2011 -0500 > summary: > Merge FYI this commit has only one parent, it's not a merge. It should have a changelog describing the patch. ... whereas the following commit has two parents, it's a merge: > http://hg.python.org/cpython/rev/567f30527913 > changeset: 70714:567f30527913 > parent: 70712:964d0d65a2a9 > parent: 70713:88e318166eaf > user: Brian Curtin <brian(a)python.org> > date: Wed Jun 08 18:43:57 2011 -0500 > summary: > Fix #11583. Changed os.path.isdir to use GetFileAttributes (...) You can use "merge", "Merge 3.2", or other similir changelog. I prefer to use "(Merge 3.2)Fix #11583. Changed os.path._isdir ..." : copy/paste the changelog of the original commit with "(Merge 3.2) " prefix. Victor

1 0

Byte filenames in the posix module on Windows
by Victor Stinner 08 Jun '11

08 Jun '11

Hi, Last november, we "decided" (right?) to deprecate bytes filenames in the posix module on Windows in Python 3.2 and drop the support in 3.3: see "Removal of Win32 ANSI API" thread on python-dev. Python 3.2 has been released, so we should shift the versions numbers. I would like to take care of this. I propose three steps: 1) Remove the bytes implementation of each function (when the code is not shared with other OSes), decode bytes from MBCS and reuse the Unicode code. 2) Deprecate the bytes code in Python 3.3 3) Drop bytes support in Python 3.4 (I'm only talking about the posix module on Windows) The first step should not change anything for the user, but it will remove a lot of duplicated code. I expect something like removing the half of the code specific to Windows in the posix module. If we decide to keep bytes filenames on Windows, we can stop before the second step. -- One important point is the choice of the error handler: I would like to mimic the ANSI API and so I will use MultiByteToWideChar() with flags=0 (e.g. MBCS codec with ignore error handler, but see also the issue #12281 !). The MBCS codec uses the ANSI code page which can be a multibyte encoding, like ShiftJIS (cp932 with a japanese locale). os.fsdecode(), PyUnicode_DecodeFSDefault() and PyUnicode_FSDecoder() use the strict error handler to decode filenames on Windows. We may also use strict in the posix module. I'm +0 for this because it warns the developer (and user?) that he/she is doing something really bad. -- I would like to simplify posixmodule.c because I saw that it is difficult to patch it to fix bugs (you have to patch two functions, or more, for each fix). A recent example is the os.stat() symlink issue on Windows: http://bugs.python.org/issue12084 Since Windows 2000, filenames are stored as Unicode internally (e.g. VFAT and NTFS use UTF-16), the ANSI API was kept for backward compatibility (for lazy developers!). If you use bytes for filenames on Windows, you may get encode errors because the ANSI code page is a small subset of Unicode. For your information, I have a last -huge- pending patch to only use Unicode in the import machinery, issue #11619 ;-) Using this patch, you can use characters not encodable to the ANSI code page in your module name/path, yeah! But I am not completly convinced that we need this patch... Victor

1 0

AIX 5.3 - Build of Python 2.7.1
by Anurag Chourasia 07 Jun '11

07 Jun '11

Hi All, Python2.7.1 build on AIX 5.3 ML 12 is failing at the make step with the error indicated below de -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -ldl -o Parser/pgen ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 559) in object Parser/grammar1.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 579) in object Parser/firstsets.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. collect2: ld returned 12 exit status make: 1254-004 The error code from the last command is 1. Is there anything I could try to get past this? Here is the configuration and make step that i utilized ./configure –enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses" make Regards, Anurag

2 1

Re: [Python-Dev] [Python-checkins] cpython: Issue #12040: Expose a new attribute `sentinel` on instances of
by Nick Coghlan 07 Jun '11

07 Jun '11

On Tue, Jun 7, 2011 at 6:22 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > On Tue, 7 Jun 2011 12:47:37 +1000 > Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> >> We should probably follow this model for threading.Thread.ident as >> well (i.e. throwing an exception rather than returning None if the >> thread hasn't been started yet). > > Well, Process.ident returns None as well ;) Hmm, I guess in that case my preference for keeping the Thread and Process APIs reasonably consistent just edges out my dislike of returning None when a "you shouldn't do that" exception would be more appropriate. >> Also, for runtime state errors, we tend to use RuntimeError rather >> than ValueError (e.g. see the errors thrown by >> contextlib._GeneratorContextManager) > > Well, it depends. For example, closed files raise a ValueError when you > try to do operations on them. I tend to think of RuntimeError as > something that happens without any clear responsibility from the user, > although that's debatable (recursion errors can occur because of a > programming bug, but also simply because a structure is nested much too > deeply). Yeah, I only thought of the closed file counterexample after I had already posted. I guess I just have a slight personal preference for RuntimeError to flag state problems as they're less likely to be caught up in an overly broad try statement in user code (as catching RuntimeError seems to be less common than catching ValueError). > Of course, current coding practice in other multiprocessing.Process > methods and properties doesn't help, since it uses asserts to guard > against misuse! I have a vague recollection of an existing tracker issue complaining about that... or am I just remembering the one that addressed similar problems in threading? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #12040: Expose a new attribute `sentinel` on instances of
by Nick Coghlan 07 Jun '11

07 Jun '11

On Tue, Jun 7, 2011 at 3:36 AM, antoine.pitrou <python-checkins(a)python.org> wrote: > + @property > + def sentinel(self): > + ''' > + Return a file descriptor (Unix) or handle (Windows) suitable for > + waiting for process termination. > + ''' > + try: > + return self._sentinel > + except AttributeError: > + raise ValueError("process not started") > + We should probably follow this model for threading.Thread.ident as well (i.e. throwing an exception rather than returning None if the thread hasn't been started yet). Also, for runtime state errors, we tend to use RuntimeError rather than ValueError (e.g. see the errors thrown by contextlib._GeneratorContextManager) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Help requested for Python ISO Standard
by kevin coyne 07 Jun '11

07 Jun '11

To whom it may concern: I am working on an ISO Annex of Vulnerabilities for the Python language and am asking for help getting a list of language features that exhibit: unspecified behavior, undefined behavior, or implementation defined behavior. I am also searching for a list of deprecated features. Guido (copied) had suggested I contact you folks for help as we are coming up on an ISO deadline and I have not been successful finding this information. Thanks very much in advance for your help! Regards, Kevin Coyne Cell: 703.901.6774

3 3

FWD: gpg keys have problems
by Aahz 06 Jun '11

06 Jun '11

I'm not currently reading python-dev, dunno if this has come up before: ----- Forwarded message from "Michael J. Dinneen" <mjd(a)cs.auckland.ac.nz> ----- > Date: Sun, 05 Jun 2011 19:33:04 +1200 > From: "Michael J. Dinneen" <mjd(a)cs.auckland.ac.nz> > To: webmaster(a)python.org > Subject: gpg keys have problems > Organization: University of Auckland > > >From your python download page you need to update the public keys to not use the faulty MD5 digest algorithm. > (see the link listed below) > > $ gpg --import pubkeys.txt > gpg: key 6A45C816: public key "Anthony Baxter <anthony(a)interlink.com.au>" imported > gpg: WARNING: digest algorithm MD5 is deprecated > gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information > gpg: key ED9D77D5: public key "Barry A. Warsaw <barry(a)warsaw.us>" imported > gpg: Total number processed: 2 > gpg: imported: 2 (RSA: 1) > gpg: no ultimately trusted keys found > ----- End forwarded message ----- -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Looking back over the years, after I learned Python I realized that I never really had enjoyed programming before.

2 1

Buildbots and regrtest timeout
by Victor Stinner 06 Jun '11

06 Jun '11

Hi, Stephan Krah asked me to change how the default timeout is defined for regrtest (issue #12250): "The implicit timeout in regrtest.py makes it harder to write automated test scripts for 3rd party modules. First, you have to remember to set --timeout=0 for long running tests. Then, you have to remember not to use the --timeout option when compiling --without-threads. I'd much prefer that there's no timeout unless explicitly specified. For the buildbots, I think this could be done in the Makefile." First I replaced the hardcoded constant in regrtest.py by a command line argument (--timeout=3600) in the TESTOPTS variable of the Makefile, so if you call regrtest directly (without make), there is no more default timeout. But today I saw a a buildbot timeout without any traceback: a possible hang in test_io on "x86 FreeBSD 7.2 3.x" buildbot, "command timed out: 3900 seconds without output". I realized that some buildbots (all buildbots?) override the TESTOPTS variable ("make buildbottest TESTOPTS= TESTPYTHONOPTS=" for "x86 FreeBSD 7.2 3.x"). I moved the timeout option from TESTOPTS to a new variable: TESTTIMEOUT, with a default value of 1 hour (3600 seconds). The timeout is now only used for "make buildbottest". Use TESTTIMEOUT=0 to disable completly regrtest timeout. The timeout argument if ignored (with a warning) if faulthandler.dump_tracebacks_later() function is missing (e.g. if Python is compiled without threads). Please, don't disable the TESTTIMEOUT option for your buildbot. You may want to use a shorter or longer timeout, it just have to be smaller than the buildbot timeout (3900 seconds by default, 1 hour 6 minutes, just a little bit more than regrtest timeout: 1 hour). If you want a timeout longer than 1 hour, you can to change TESTTIMEOUT and the buildbot timeout (I don't know how to configure the buildbot timeout). I didn't touch test, testall, testuniversal, quicktest make rules, which don't use the regrtest timeout anymore. I would prefer to use the same timeout options for all test rules in TESTOPTS, but it doesn't work because some buildbots do override TESTOPTS variable. Victor

3 2

packaging landed in stdlib
by Tarek Ziadé 06 Jun '11

06 Jun '11

Hey I've pushed packaging in stdlib. There are a few buildbots errors we're fixing right now. We will continue our work in their directly for now on. The next "big" commit will be for the documentation, Cheers Tarek -- Tarek Ziadé | http://ziade.org

3 4

Re: [Python-Dev] cpython: always clear parser error
by Georg Brandl 06 Jun '11

06 Jun '11

On 06/06/11 05:13, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9faa9270457e > changeset: 70654:9faa9270457e > user: Benjamin Peterson <benjamin(a)python.org> > date: Sun Jun 05 22:14:05 2011 -0500 > summary: > always clear parser error > > files: > Modules/parsermodule.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) This looks like a fixup of rev 3ffd8dea77bf; it would be nice to say so in the commit message: the current message is not obvious at all. Georg

1 0

Add LRUCache class to stdlib
by Nadeem Vawda 06 Jun '11

06 Jun '11

I would like to propose adding a class to the stdlib to provide a more flexible LRU caching mechanism. As things stand, the functools.lru_cache() decorator is fine for memoization of pure functions, but does not accommodate situations where cache entries become stale and must be invalidated/updated (e.g. filecmp.cmp(); cf. issue #11802). I was thinking it would be a good idea to factor out the the replacement code into a separate class that could then be reused by code for which the lru_cache() decorator is not applicable. The implementation of lru_cache() itself would also become considerably simpler. Implementation: class LRUCache: """Least-recently-used cache class. See: http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used """ def __init__(self, maxsize): """Initialize an LRUCache. If *maxsize* is None, the LRU replacement mechanism is disabled, and the cache can grow without bound. """ if maxsize is None: self.cache = dict() else: self.cache = OrderedDict() self.lock = Lock() self.hits = self.misses = 0 self.maxsize = maxsize def __getitem__(self, key): with self.lock: try: value = self.cache[key] except KeyError: self.misses += 1 raise else: self.hits += 1 if self.maxsize is not None: self.cache.move_to_end(key) return value def __setitem__(self, key, value): with self.lock: self.cache[key] = value if self.maxsize is not None and len(self.cache) > self.maxsize: self.cache.popitem(0) def info(self): """Report cache statistics""" with self.lock: return _CacheInfo(self.hits, self.misses, self.maxsize, len(self.cache)) I'm not sure where this class should go; it would be convenient to just stick it in functools along with lru_cache(), but perhaps the collections package would be more appropriate? Cheers, Nadeem

1 0

keyword-only arguments and varags
by Benjamin Peterson 05 Jun '11

05 Jun '11

Currently, def f(*, kw, **kwargs): pass is valid syntax, but def f(*args, *, kw): pass is not. I don't see any mention of it in the PEP but perhaps there is a good reason this isn't allowed. It seems to be perfectly well-defined to me. -- Regards, Benjamin

2 2

Re: [Python-Dev] [Python-checkins] cpython (3.1): Do not add txt files twice.
by Victor Stinner 05 Jun '11

05 Jun '11

I added the "if dir=='cjkencodings':" to msi.py, based on tests for other subdirectories in Lib/tests/. Can you explain me why cjkencodings should not have a special case? The fix should maybe be ported to 3.2, 3.3 and 2.7. Victor Le dimanche 05 juin 2011 11:00:30, martin.v.loewis a écrit : > http://hg.python.org/cpython/rev/df7b9c5d6ba1 > changeset: 70643:df7b9c5d6ba1 > branch: 3.1 > parent: 70571:0639e630426c > user: Martin v. Löwis <martin(a)v.loewis.de> > date: Sun Jun 05 10:55:57 2011 +0200 > summary: > Do not add txt files twice. > > files: > Tools/msi/msi.py | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > > diff --git a/Tools/msi/msi.py b/Tools/msi/msi.py > --- a/Tools/msi/msi.py > +++ b/Tools/msi/msi.py > @@ -1021,8 +1021,6 @@ > lib.add_file("zipdir.zip") > if dir=='tests' and parent.physical=='distutils': > lib.add_file("Setup.sample") > - if dir=='cjkencodings': > - lib.glob("*.txt") > if dir=='decimaltestdata': > lib.glob("*.decTest") > if dir=='output':

1 0

Re: [Python-Dev] [Python-checkins] cpython: Add NEWS and whatsnew entries for the packaging module
by Victor Stinner 04 Jun '11

04 Jun '11

Le vendredi 03 juin 2011 17:28:48, eric.araujo a écrit : > +packaging > +--------- > + > +:mod:`distutils` has undergone additions and refactoring under a new name, > +:mod:`packaging`, to allow developers to break backward compatibility. > +:mod:`distutils` is still provided in the standard library, but users are > +encouraged to transition to :mod:`packaging`. For older versions of > Python, a +backport compatible with 2.4+ and 3.1+ will be made available > on PyPI under the +name :mod:`distutils2`. Even for Python 2.4, really? Do you really need to support this old Python release? Victor

4 3

Released: Python 2.6.7
by Barry Warsaw 04 Jun '11

04 Jun '11

Hello Pythoneers and Pythonistas, I'm happy to announce the final release of Python 2.6.7. Python 2.6 is in security-fix only mode. This means that general bug maintenance has ended, and only critical security issues are being fixed. We will support Python 2.6 in security-fix only mode until October 2013. Also, this is a source-only release; no installers for Windows or Mac OS X will be provided. Please download the source from: http://www.python.org/download/releases/2.6.7/ The NEWS file contains the list of changes since 2.6.6: http://www.python.org/download/releases/2.6.7/NEWS.txt Many thanks go out to the entire Python community for their contributions and help in making Python 2.6.7 available. Enjoy, -Barry (on behalf of the Python development community)

1 0

Sniffing passwords from PyPI using insecure connection
by anatoly techtonik 04 Jun '11

04 Jun '11

Hi, I'd like to escalate http://bugs.python.org/issue12226 : 'use secured channel for uploading packages to pypi' to be shipped with next Python 2.6+ This will prevent pydotorg password sniffing when submitting packages through public networks (such as hotels). -- anatoly t.

5 6

Extending os.chown() to accept user/group names
by Sandro Tosi 03 Jun '11

03 Jun '11

Hi all, before opening an issue to track the request, I'd like to ask advice here about this: extend os.chown() to accept even user/group names instead of just uid and gid. On a Unix system, you can call chown command passing either id or names, so it seems (to me at least) natural to expect os.chown() to behave similarly; but that's not the case. I can see os module wants to be a thin wrapper around OS syscalls and chown(2) accepts only uid/gid as input, so what would be best: extend os.chown() or provide a chown() function in shutil module for this purpose? Thanks in advance, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi

14 18

Re: [Python-Dev] [Python-checkins] cpython: Fix reST label for collections ABCs.
by Raymond Hettinger 03 Jun '11

03 Jun '11

On Jun 3, 2011, at 10:27 AM, eric.araujo wrote: > > Fix reST label for collections ABCs. > > The previous markup hijacked the abstract-base-classes glossary entry, > which resulted in the HTML linking to collections.abc when defining the > generic ABC concept. Now the glossary links to the abc module. I think the users are better served by links to collections.abc, io.abc, etc. For the most part, glossary readers will be interested in actual abstract classes than in the underlying implementation. IOW, I believe this edit makes the docs worse rather than better. Raymond

2 1

Summary of Python tracker Issues
by Python tracker 03 Jun '11

03 Jun '11

ACTIVITY SUMMARY (2011-05-27 - 2011-06-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2815 ( +2) closed 21221 (+56) total 24036 (+58) Open issues with patches: 1224 Issues opened (38) ================== #12197: non-blocking SSL write in Windows sends large data but raises http://bugs.python.org/issue12197 opened by dsiroky #12198: zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= http://bugs.python.org/issue12198 opened by gnezdo #12200: bdist_wininst install_script not run on uninstall http://bugs.python.org/issue12200 opened by mhammond #12201: Returning FILETIME is unsupported in msilib.SummaryInformation http://bugs.python.org/issue12201 opened by markm #12202: Check status returns in msilib.SummaryInformation.GetProperty( http://bugs.python.org/issue12202 opened by markm #12204: str.upper converts to title http://bugs.python.org/issue12204 opened by py.user #12206: Documentation Std. Library 15.7.5 "LogRecord objects": Paramet http://bugs.python.org/issue12206 opened by mponweiser #12207: Document ast.PyCF_ONLY_AST http://bugs.python.org/issue12207 opened by eric.araujo #12208: Glitches in email.policy docs http://bugs.python.org/issue12208 opened by eric.araujo #12209: Minor edits to faulthandler doc http://bugs.python.org/issue12209 opened by eric.araujo #12210: test_smtplib: intermittent failures on FreeBSD http://bugs.python.org/issue12210 opened by skrah #12211: math.copysign must keep object type. http://bugs.python.org/issue12211 opened by umedoblock #12213: BufferedRandom, BufferedRWPair: issues with interlaced read-wr http://bugs.python.org/issue12213 opened by haypo #12214: platform module can't detect archlinux distribution http://bugs.python.org/issue12214 opened by lilaboc #12215: TextIOWrapper: issues with interlaced read-write http://bugs.python.org/issue12215 opened by haypo #12217: Cross-link docs for faulthandler, traceback and pdb http://bugs.python.org/issue12217 opened by eric.araujo #12219: tkinter.filedialog.askopenfilename XT dialog on Windows 7 http://bugs.python.org/issue12219 opened by hfischer #12220: minidom xmlns not handling spaces in xmlns attribute value fie http://bugs.python.org/issue12220 opened by hfischer #12222: All pysetup commands should respect exit codes http://bugs.python.org/issue12222 opened by tarek #12223: Datamodel documentation page: 'operator' where 'operand' shoul http://bugs.python.org/issue12223 opened by Vladimir.M. #12224: problem with siginterrupt http://bugs.python.org/issue12224 opened by Zhiping.Deng #12226: use secured channel for uploading packages to pypi http://bugs.python.org/issue12226 opened by techtonik #12228: Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK description http://bugs.python.org/issue12228 opened by sandro.tosi #12231: regrtest: add -k and -K options to filter tests by function/fi http://bugs.python.org/issue12231 opened by haypo #12232: embedded python import cmath http://bugs.python.org/issue12232 opened by Thanh Ly #12234: unittest2 could enable regex debugging for more information http://bugs.python.org/issue12234 opened by iElectric #12237: Document how to open non-default webbrowser http://bugs.python.org/issue12237 opened by hirsh #12238: Readline module loading in interactive mode http://bugs.python.org/issue12238 opened by Niels.Heinen #12239: msilib VT_EMPTY SummaryInformation properties raise an error ( http://bugs.python.org/issue12239 opened by markm #12240: Allow multiple setup_hooks http://bugs.python.org/issue12240 opened by erik.bray #12242: distutils2 environment marker for current compiler http://bugs.python.org/issue12242 opened by eli.collins #12243: getpass.getuser works on OSX http://bugs.python.org/issue12243 opened by louiscipher #12245: Document the meaning of FLT_ROUNDS constants for sys.float_inf http://bugs.python.org/issue12245 opened by rhettinger #12246: create installation path if it's non-existent http://bugs.python.org/issue12246 opened by tshepang #12248: __dir__ semantics changed in Python 2.7.2 http://bugs.python.org/issue12248 opened by barry #12249: add missing command http://bugs.python.org/issue12249 opened by tshepang #12253: Document packaging.manifest and packaging.errors http://bugs.python.org/issue12253 opened by eric.araujo #12254: PEP-3107 has a wrong attribute name for function annotations http://bugs.python.org/issue12254 opened by Roman.Alexeev Most recent 15 issues with no replies (15) ========================================== #12254: PEP-3107 has a wrong attribute name for function annotations http://bugs.python.org/issue12254 #12253: Document packaging.manifest and packaging.errors http://bugs.python.org/issue12253 #12245: Document the meaning of FLT_ROUNDS constants for sys.float_inf http://bugs.python.org/issue12245 #12242: distutils2 environment marker for current compiler http://bugs.python.org/issue12242 #12239: msilib VT_EMPTY SummaryInformation properties raise an error ( http://bugs.python.org/issue12239 #12232: embedded python import cmath http://bugs.python.org/issue12232 #12228: Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK description http://bugs.python.org/issue12228 #12223: Datamodel documentation page: 'operator' where 'operand' shoul http://bugs.python.org/issue12223 #12220: minidom xmlns not handling spaces in xmlns attribute value fie http://bugs.python.org/issue12220 #12217: Cross-link docs for faulthandler, traceback and pdb http://bugs.python.org/issue12217 #12214: platform module can't detect archlinux distribution http://bugs.python.org/issue12214 #12208: Glitches in email.policy docs http://bugs.python.org/issue12208 #12201: Returning FILETIME is unsupported in msilib.SummaryInformation http://bugs.python.org/issue12201 #12197: non-blocking SSL write in Windows sends large data but raises http://bugs.python.org/issue12197 #12179: Race condition using PyGILState_Ensure on a new thread http://bugs.python.org/issue12179 Most recent 15 issues waiting for review (15) ============================================= #12249: add missing command http://bugs.python.org/issue12249 #12246: create installation path if it's non-existent http://bugs.python.org/issue12246 #12243: getpass.getuser works on OSX http://bugs.python.org/issue12243 #12231: regrtest: add -k and -K options to filter tests by function/fi http://bugs.python.org/issue12231 #12228: Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK description http://bugs.python.org/issue12228 #12226: use secured channel for uploading packages to pypi http://bugs.python.org/issue12226 #12215: TextIOWrapper: issues with interlaced read-write http://bugs.python.org/issue12215 #12214: platform module can't detect archlinux distribution http://bugs.python.org/issue12214 #12213: BufferedRandom, BufferedRWPair: issues with interlaced read-wr http://bugs.python.org/issue12213 #12210: test_smtplib: intermittent failures on FreeBSD http://bugs.python.org/issue12210 #12209: Minor edits to faulthandler doc http://bugs.python.org/issue12209 #12208: Glitches in email.policy docs http://bugs.python.org/issue12208 #12207: Document ast.PyCF_ONLY_AST http://bugs.python.org/issue12207 #12202: Check status returns in msilib.SummaryInformation.GetProperty( http://bugs.python.org/issue12202 #12201: Returning FILETIME is unsupported in msilib.SummaryInformation http://bugs.python.org/issue12201 Top 10 most discussed issues (10) ================================= #11975: Fix referencing of built-in types (list, int, ...) http://bugs.python.org/issue11975 19 msgs #11416: netrc module does not handle multiple entries for a single hos http://bugs.python.org/issue11416 13 msgs #12226: use secured channel for uploading packages to pypi http://bugs.python.org/issue12226 12 msgs #12185: Decimal documentation lists "first" and "second" arguments, sh http://bugs.python.org/issue12185 10 msgs #11623: Distutils is reporting OSX 10.6 w/ XCode 4 as "universal" http://bugs.python.org/issue11623 9 msgs #11906: test_argparse failure in interactive mode http://bugs.python.org/issue11906 8 msgs #12082: Python/import.c still references fstat even with DONT_HAVE_FST http://bugs.python.org/issue12082 7 msgs #6490: os.popen documentation in 2.6 is probably wrong http://bugs.python.org/issue6490 5 msgs #12191: Add shutil.chown to allow to use user and group name (and not http://bugs.python.org/issue12191 5 msgs #12246: create installation path if it's non-existent http://bugs.python.org/issue12246 5 msgs Issues closed (47) ================== #3265: Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ http://bugs.python.org/issue3265 closed by terry.reedy #8578: PyWeakref_GetObject http://bugs.python.org/issue8578 closed by python-dev #8678: crashers in rgbimg http://bugs.python.org/issue8678 closed by terry.reedy #9382: os.popen referenced but not documented in Python 3.x http://bugs.python.org/issue9382 closed by eric.araujo #9738: Document the encoding of functions bytes arguments of the C AP http://bugs.python.org/issue9738 closed by haypo #9812: cPickle segfault with nested dicts in threaded env http://bugs.python.org/issue9812 closed by terry.reedy #10449: “os.environ was modified by test_httpservers” http://bugs.python.org/issue10449 closed by eric.araujo #10616: Change PyObject_AsCharBuffer() error message http://bugs.python.org/issue10616 closed by python-dev #11217: python-32 not linked in /usr/local/bin in framework builds http://bugs.python.org/issue11217 closed by ned.deily #11449: tarfile tries to file_.tell() even when creating a new archive http://bugs.python.org/issue11449 closed by strombrg #11612: xml.dom.minidom fail to parse SVG file. http://bugs.python.org/issue11612 closed by ned.deily #11864: sporadic failure in test_concurrent_futures http://bugs.python.org/issue11864 closed by bquinlan #12028: threading._get_ident(): remove it in the doc or make it public http://bugs.python.org/issue12028 closed by python-dev #12057: HZ codec has no test http://bugs.python.org/issue12057 closed by haypo #12085: subprocess.Popen.__del__ raises AttributeError if __init__ was http://bugs.python.org/issue12085 closed by python-dev #12089: regrtest.py doesn't check for unexpected output anymore? http://bugs.python.org/issue12089 closed by python-dev #12101: PEPs should have consecutive revision numbers http://bugs.python.org/issue12101 closed by eric.araujo #12106: reflect syntatic sugar in with ast http://bugs.python.org/issue12106 closed by python-dev #12125: test_sysconfig fails on OpenIndiana because of test_packaging http://bugs.python.org/issue12125 closed by tarek #12151: test_logging fails sometimes http://bugs.python.org/issue12151 closed by vinay.sajip #12171: Reset method of the incremental encoders of CJK codecs calls t http://bugs.python.org/issue12171 closed by python-dev #12175: FileIO.readall() read the file position and size at each read http://bugs.python.org/issue12175 closed by haypo #12190: intern filenames in bytecode http://bugs.python.org/issue12190 closed by benjamin.peterson #12196: add pipe2() to the os module http://bugs.python.org/issue12196 closed by charles-francois.natali #12199: Unify TryExcept and TryFinally http://bugs.python.org/issue12199 closed by python-dev #12203: isinstance not functioning as documented http://bugs.python.org/issue12203 closed by benjamin.peterson #12205: test_subprocess fails due to uninstalled test subdirectory http://bugs.python.org/issue12205 closed by ned.deily #12212: Minor proofreading typo in index.rst http://bugs.python.org/issue12212 closed by benjamin.peterson #12216: future imports change the reporting of syntaxerrors http://bugs.python.org/issue12216 closed by python-dev #12218: Removing wsgiref.egg-info http://bugs.python.org/issue12218 closed by tarek #12221: segfaults with unexpanded $Revision$ id's in release candidate http://bugs.python.org/issue12221 closed by python-dev #12225: current tip doesn't build without mercurial installed http://bugs.python.org/issue12225 closed by r.david.murray #12227: multiprocessing.Pool initialization seems to call methods it s http://bugs.python.org/issue12227 closed by Graham.Cummins #12229: Remove unused variable in bufferedio.c http://bugs.python.org/issue12229 closed by python-dev #12230: test_subprocess.test_pass_fds() failed on x86 Tiger 3.x http://bugs.python.org/issue12230 closed by python-dev #12233: Lists in class objects not independent http://bugs.python.org/issue12233 closed by rhettinger #12235: subprocess throws wrong exception if script can't be executed http://bugs.python.org/issue12235 closed by r.david.murray #12236: Tkinter __version__ uses subversion substitution http://bugs.python.org/issue12236 closed by benjamin.peterson #12241: email.header.Header encoding fails on empty header http://bugs.python.org/issue12241 closed by r.david.murray #12244: cStringIO inconsistencies http://bugs.python.org/issue12244 closed by georg.brandl #12247: Finding subprocess.py depends on how IDLE is opened http://bugs.python.org/issue12247 closed by ned.deily #12250: regrtest: make --timeout explicit http://bugs.python.org/issue12250 closed by python-dev #12251: subprocess(..., stdout=sys.stderr) closes stderr for child http://bugs.python.org/issue12251 closed by charles-francois.natali #12252: '\u' in unicode raw string raise an syntax error http://bugs.python.org/issue12252 closed by amaury.forgeotdarc #1495802: cygwin: popen3 lock up http://bugs.python.org/issue1495802 closed by charles-francois.natali #1189811: pydoc may hide non-private doc strings. http://bugs.python.org/issue1189811 closed by ncoghlan #985064: plistlib crashes too easily on bad files http://bugs.python.org/issue985064 closed by ned.deily

1 0

Re: [Python-Dev] [Python-checkins] peps: Add rules for indenting continuation lines.
by Barry Warsaw 03 Jun '11

03 Jun '11

On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote: >+ Continuation lines should align wrapped elements either vertically using >+ Python's implicit line joining inside parentheses, brackets and braces, >+ or using a hanging indent of double your code indention, in which case >+ there should be no argument on the first line. For example: >+ >+ Yes: # Aligned with opening delimiter >+ foo = long_function_name(var_one, var_two, >+ var_three, var_four) >+ >+ # Double code indention for hanging indent; nothing on first line >+ foo = long_function_name( >+ var_one, var_two, var_three, >+ var_four) >+ >+ No: # Stuff on first line forbidden >+ foo = long_function_name(var_one, var_two, >+ var_three, var_four) >+ >+ # 2-space hanging indent forbidden >+ foo = long_function_name( >+ var_one, var_two, var_three, >+ var_four) As I mentioned to Guido, I'm not sure where the double-indent recommendation comes from, but it's entirely possible I missed that discussion. I agree with the recommendations, but think a single-indentation level looks fine. E.g. return dict( fqdn_listname=member.mailing_list, address=member.address.email, role=role, user=path_to('users/{0}'.format(member.user.user_id)), self_link=path_to('members/{0}'.format(member.member_id)), ) or return b'{0}://{1}:{2}/{3}/{4}'.format( ('https' if as_boolean(config.webservice.use_https) else 'http'), config.webservice.hostname, config.webservice.port, config.webservice.api_version, (resource[1:] if resource.startswith('/') else resource), ) -Barry

7 12

Windows download links not working for 2.7.2rc1 and 3.1.4rc1
by Michael Foord 02 Jun '11

02 Jun '11

Hey all, The links to the Windows downloads for 2.7.2rc1 and 3.1.4rc1 are 404. (From the release pages.) http://python.org/ftp/python/3.1.3/python-3.1.4rc1.msi http://python.org/ftp/python/2.7.1/python-2.7.2rc1.msi All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

2 1

Re: [Python-Dev] [Python-checkins] cpython: The compiler class for EMX was removed
by Nick Coghlan 02 Jun '11

02 Jun '11

On Thu, Jun 2, 2011 at 3:47 AM, eric.araujo <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/c3f8991cd74d > changeset: 70587:c3f8991cd74d > user: Éric Araujo <merwok(a)netwok.org> > date: Wed Jun 01 15:20:44 2011 +0200 > summary: > The compiler class for EMX was removed This is the kind of checkin comment where the phrasing is a little confusing. It could mean either "was removed by mistake and has now been restored" or else "is no longer supported and has been removed". (Checking the diff resolves the ambiguity in favour of the latter interpretation, but not all diffs are as simple as this one). It's worth trying to make the final state of the source tree explicit in the checkin message (no need to edit the history, just a note for future reference). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Re: [Python-Dev] [Python-checkins] cpython (2.7): Multiple clean-ups to the docs for builtin functions.
by Terry Reedy 02 Jun '11

02 Jun '11

On 6/1/2011 6:50 PM, raymond.hettinger wrote: > - with open("mydata.txt") as fp: > - for line in iter(fp.readline, "STOP"): > process_line(line) As noted on the tracker, this will always loop forever. Even if "STOP" is corrected to "STOP\n", it will still loop forever if the file does not have the magic value. > + with open('mydata.txt') as fp: > + for line in iter(fp.readline, ''): > process_line(line) While I have a big problem with infinite loops, I have a (smaller) problem with useless code. The new loop line line is a roundabout way to spell "for line in fp". While this would have been useful before files were turned into iterables (if there was such a time after iter() was introduced), it is not now. What might be useful and what the example could show is how to stop early if a sentinel is present, while still stopping when the iterable runs out. The following alternate fix to the original does just that. with open("mydata.txt") as fp: for line in iter(fp.__next__, "STOP\n"): process_line(line) A tested a runnable variation with and without the exact sentinal. It generalizes to *any* iteration than one might want to stop early. This still has the objection that the loop could be written as for line in fp: if line == "STOP\n": break process_line(line) which is easily generalized to any stopping conditions. It is hard to think of useful examples of iter(func, sentinal). To be sure of someday stopping, func must someday (either certainly or with probability 1) either raise StopIteration or produce the sentinal (which should therefore be hard to misspell). To be useful, func should not be a method of an iterable (or at least not produce the same objects as the iterable would when iterated.) It also must produce different values, at least sometimes, when called, which means either maintaining internal state or pulling values from another source. Here is a completely different example which meets these criteria. It can actually be run (though not doctested ;-). It uses random.randint to produce 25 random waiting times for a binary process to hit one of the two values. from random import randint for i in range(25): print(sum(iter(lambda:randint(0,1), 0)), end=',') The outer loop could be removed, but it hints at how this could be used for empirical probability studies. --- Terry Jan Reedy

1 0

Question about Module Loading
by Timothy Kadich 02 Jun '11

02 Jun '11

If a Python program imported a module, say numpy for example, where in the source is this line interpreted and then handled by import.c ? Thank you in advance!

3 4

Docs for the packaging module
by Éric Araujo 01 Jun '11

01 Jun '11

Hi, The docs were not added alongside the code when packaging was merged back into CPython because they were not in a shape conforming with the rest of the docs. I’d like your input on layout so that I can fix this ASAP and merge the docs. (They would still require a lot of additions, fixes and improvements after that, but at least they’d be in the repo.) The easiest part is the library documentation, i.e. the docs for developers of packaging-related tools that want to use for example packaging.version or packaging.metadata to do their own stuff. These documents should go into Doc/library/packaging.*, I think this is a no-brainer. (Distutils has only a stub here, its API docs is mixed with its usage docs.) There is a guide for end-users, which contains an outdated copy of the old “Installing Python Modules” and a few documents about the new pysetup script (superseder of setup.py scripts), which are not integrated with the first document. I think those should supersede the existing distutils-based Doc/install tree. We want to advertise pysetup and packaging as the way of gettting modules in 3.3. A question remains: is it worthwhile to keep the old document somewhere? Last but not least, the doc for authors wanting to package and distribute their project (“Distributing Python Modules”, Doc/distutils). I think we should not overwrite this directory, because the directory name is tied to distutils and because there will be users needing that documentation (distutils is not removed). So, is it okay to create a new Doc/packaging directory and change the link on the docs front page from distutils to packaging? (Technical question: I think I’ll get a complaint from Sphinx that distutils is not included in any toctree; I’ll try adding a toctree from library/distutils to distutils/index and see if that works.) Thanks for reading

4 5

Re: [Python-Dev] [Python-checkins] cpython: test.support: add requires_mac_ver() function
by Ezio Melotti 01 Jun '11

01 Jun '11

Hi, On 01/06/2011 13.28, victor.stinner wrote: > http://hg.python.org/cpython/rev/35212b113730 > changeset: 70574:35212b113730 > user: Victor Stinner<victor.stinner(a)haypocalc.com> > date: Wed Jun 01 12:28:04 2011 +0200 > summary: > test.support: add requires_mac_ver() function I would expect this to be a decorator, similar to requires_IEEE_754 and requires_zlib. > Add also linux_version() to __all__. For consistency, this should be a decorator too, possibly named requires_linux_ver(). A requires_windows(_ver) sounds like a useful addition too, given the number of tests that are specific to Windows. > files: > Lib/test/support.py | 22 +++++++++++++++++++++- > Lib/test/test_math.py | 7 ++++--- > 2 files changed, 25 insertions(+), 4 deletions(-) > > > diff --git a/Lib/test/support.py b/Lib/test/support.py > --- a/Lib/test/support.py > +++ b/Lib/test/support.py > @@ -37,7 +37,8 @@ > "Error", "TestFailed", "ResourceDenied", "import_module", > "verbose", "use_resources", "max_memuse", "record_original_stdout", > "get_original_stdout", "unload", "unlink", "rmtree", "forget", > - "is_resource_enabled", "requires", "find_unused_port", "bind_port", > + "is_resource_enabled", "requires", "linux_version", "requires_mac_ver", > + "find_unused_port", "bind_port", > "IPV6_ENABLED", "is_jython", "TESTFN", "HOST", "SAVEDCWD", "temp_cwd", > "findfile", "sortdict", "check_syntax_error", "open_urlresource", > "check_warnings", "CleanImport", "EnvironmentVarGuard", "TransientResource", > @@ -299,6 +300,25 @@ > except ValueError: > return 0, 0, 0 > > +def requires_mac_ver(*min_version): > + """Raise SkipTest if the OS is Mac OS X and the OS X version if less than > + min_version. > + > + For example, support.requires_linux_version(10, 5) raises SkipTest if the This should be requires_mac_ver > + version is less than 10.5. > + """ > + if sys.platform != 'darwin': > + return > + version_txt = platform.mac_ver()[0] > + try: > + version = tuple(map(int, version_txt.split('.'))) > + except ValueError: > + return > + if version< min_version: > + min_version_txt = '.'.join(map(str, min_version)) > + raise unittest.SkipTest("Mac OS X %s or higher required, not %s" > + % (min_version_txt, version_txt)) > + > HOST = 'localhost' > > def find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM): > diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py > --- a/Lib/test/test_math.py > +++ b/Lib/test/test_math.py > @@ -2,6 +2,7 @@ > # XXXX Should not do tests around zero only > > from test.support import run_unittest, verbose, requires_IEEE_754 > +from test import support > import unittest > import math > import os > @@ -669,10 +670,10 @@ > self.assertTrue(math.isnan(math.log2(NAN))) > > @requires_IEEE_754 > - @unittest.skipIf(sys.platform == 'darwin' > - and platform.mac_ver()[0].startswith('10.4.'), > - 'Mac OS X Tiger log2() is not accurate enough') > def testLog2Exact(self): > + # log2() is not accurate enough on Mac OS X Tiger (10.4) > + support.requires_mac_ver(10, 5) > + > # Check that we get exact equality for log2 of powers of 2. > actual = [math.log2(math.ldexp(1.0, n)) for n in range(-1074, 1024)] > expected = [float(n) for n in range(-1074, 1024)] > Best Regards, Ezio Melotti

1 0