Mailman 3 May 2012 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args
by Nadeem Vawda 30 May '12

30 May '12

Since this changeset, building on Windows seems to be broken (see http://python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/450 for example). Nadeem

4 3

Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
by Georg Brandl 30 May '12

30 May '12

Am 28.05.2012 03:55, schrieb terry.reedy: > http://hg.python.org/cpython/rev/4a7582866735 > changeset: 77195:4a7582866735 > branch: 3.2 > parent: 77189:6737c2ca98ee > user: Terry Jan Reedy <tjreedy(a)udel.edu> > date: Sun May 27 21:29:17 2012 -0400 > summary: > Issue12510: Attempting to get invalid tooltip no longer closes Idle. > Original patch by Roger Serwy. > > files: > Lib/idlelib/CallTips.py | 9 ++++++--- > Misc/NEWS | 3 +++ > 2 files changed, 9 insertions(+), 3 deletions(-) > > > diff --git a/Lib/idlelib/CallTips.py b/Lib/idlelib/CallTips.py > --- a/Lib/idlelib/CallTips.py > +++ b/Lib/idlelib/CallTips.py > @@ -110,7 +110,9 @@ > namespace.update(__main__.__dict__) > try: > return eval(name, namespace) > - except (NameError, AttributeError): > + # any exception is possible if evalfuncs True in open_calltip > + # at least Syntax, Name, Attribute, Index, and Key E. if not Is something missing here? The comment text seems cut off. > + except: > return None "except Exception" may be better here. Georg

3 4

PEP 405 (Python Virtual Environments) and Windows script support
by Vinay Sajip 29 May '12

29 May '12

In the recent check-in I made of the PEP 405 functionality, there is a Windows executable. Antoine asked what this was in his comment on the checkin, but I couldn't respond via Gmane (my usual method) as for some reason his post doesn't appear there. PEP 397 (Python launcher for Windows) has not yet been accepted, so there still needs to be some way of natively launching scripts in Windows which is equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute) does this is to shadow each script with an executable: whereas a script foo would be simply placed in /path/to/venv/bin/ on POSIX, on Windows, the files foo.exe and foo-script.py (or foo-script.pyw) are placed in \path\to\venv\Scripts. The user can run \path\to\venv\Scripts\foo just as on POSIX. The foo.exe file is just a copy of a stock launcher executable which finds its name from the C argv[0], and based in that name (foo in this case), invokes foo-script.py or foo-script.pyw with the appropriate Python interpreter. There are two versions of the launcher - console and Windows - built from the same source. These append -script.py and -script.pyw respectively, hard-coded into the executable. The idea is for packaging to do the appropriate copying of stock-launcher.exe to foo.exe when installing scripts. AFAIK this is not yet in packaging, but I implemented it in the pythonv branch (that code was not part of the PEP 405 implementation - it just allowed me to explore how venvs would work with packaging on Windows). The setuptools versions of these scripts are compiled using MinGW. I don't know if we can use them as is, and as the functionality is fairly simple, I implemented it in a separate project using MSVC: https://bitbucket.org/vinay.sajip/simple_launcher We may not need any of this, if PEP 397 is accepted in time. However, if it isn't, I would expect that something like these launchers will be needed. In my packaging code in the pythonv branch, there are different variants - t32.exe, t64.exe, w32.exe, w64.exe - one of which is picked as the source for copying to the destination when installing a script. These .exes are UPX-compressed versions of the executables created by the Microsoft compiler and linker (using static linking). Comments welcome, especially on whether Windows users agree that something like this is needed in the absence of PEP 397 in Python 3.3. Regards, Vinay Sajip

7 14

Missing command line documentation for new tools
by Nick Coghlan 29 May '12

29 May '12

The documentation does not currently provide end user guides for pysetup or pyvenv under http://docs.python.org/dev/using/index.html This needs to be fixed before 3.3 is released. I've created the following issues as deferred blockers (since they don't need to be addressed before the alpha this week): pysetup: http://bugs.python.org/issue14940 pyvenv: http://bugs.python.org/issue14939 As the standard library comes to include more directly executed tools, we really need to focus on keeping the Setup & Usage docs up to date. The fact we've been historically lax on that front is no excuse for perpetuating the problem for new additions. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 3

Re: [Python-Dev] [Python-checkins] cpython: Issue 14814: Add namespaces keyword arg to find(*) methods in _elementtree.
by Nick Coghlan 29 May '12

29 May '12

On Tue, May 29, 2012 at 1:03 PM, eli.bendersky <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/7d252dbfbee3 > changeset: 77217:7d252dbfbee3 > user: Eli Bendersky <eliben(a)gmail.com> > date: Tue May 29 06:02:56 2012 +0300 > summary: > Issue 14814: Add namespaces keyword arg to find(*) methods in _elementtree. > Add attrib keyword to Element and SubElement in _elementtree. > Patch developed with Ezio Melotti. I'm not sure which issue you intended to reference here, but I'm fairly sure the PEP 3144 integration issue wasn't it :) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-Dev] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
by Georg Brandl 29 May '12

29 May '12

Am 25.05.2012 07:54, schrieb benjamin.peterson: > http://hg.python.org/cpython/rev/a47d32a28662 > changeset: 77129:a47d32a28662 > user: Benjamin Peterson <benjamin(a)python.org> > date: Thu May 24 22:54:15 2012 -0700 > summary: > simplify and rewrite the zipimport part of 702009f3c0b1 a bit > > files: > Modules/zipimport.c | 92 ++++++++++++++------------------ > 1 files changed, 41 insertions(+), 51 deletions(-) > > > diff --git a/Modules/zipimport.c b/Modules/zipimport.c > --- a/Modules/zipimport.c > +++ b/Modules/zipimport.c > @@ -319,13 +319,20 @@ > return MI_NOT_FOUND; > } > > +typedef enum { > + fl_error, > + fl_not_found, > + fl_module_found, > + fl_ns_found > +} find_loader_result; This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values. (There's one exception, but also recently committed, in posixmodule.c for the utime_result enum. Maybe that could also be fixed.) Georg

4 3

Proposal for better SSL errors
by Antoine Pitrou 28 May '12

28 May '12

Hello, In http://bugs.python.org/issue14837 I have attached a proof-of-concept patch to improve the exceptions raised by the ssl module when OpenSSL signals an error. The current situation is quite dismal, since you get a sometimes cryptic error message with no viable opportunities for programmatic introspection: >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) >>> ctx.verify_mode = ssl.CERT_REQUIRED >>> sock = socket.create_connection(("svn.python.org", 443)) >>> sock = ctx.wrap_socket(sock) Traceback (most recent call last): [...] ssl.SSLError: [Errno 1] _ssl.c:420: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed SSLError instances only have a "errno" attribute which doesn't actually contain a meaningful value. With the posted patch, the above error becomes: >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) >>> ctx.verify_mode = ssl.CERT_REQUIRED >>> sock = socket.create_connection(("svn.python.org", 443)) >>> sock = ctx.wrap_socket(sock) Traceback (most recent call last): [...] ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:494) [88296 refs] Not only does the error string contain more valuable information (the mnemonics "SSL" and "CERTIFICATE_VERIFY_FAILED" indicate, respectively, in which subpart of OpenSSL and which precise error occurred), but they are also introspectable: >>> e = sys.last_value >>> e.library 'SSL' >>> e.reason 'CERTIFICATE_VERIFY_FAILED' (these mnemonics correspond to OpenSSL's own #define'd numeric codes. I find it more Pythonic to expose the mnemonics than the numbers, though. Of course, the numbers <-> mnemnonics mappings can be separately exposed) You'll note there is still a "Errno 5" in that error message; I don't really know what to do with it. Hard-wiring the errno attribute to something like None *might* break existing software, although that would be unlikely since the current errno value is quite meaningless and confusing (it has nothing to do with POSIX errnos). To clarify a bit my request, I am asking for feedback on the principle more than on the implementation right now. Regards Antoine.

4 7

Hacking on the compiler in ways that break the frozen instance of importlib...
by Nick Coghlan 27 May '12

27 May '12

So, I'm currently trying to fix the regression in handling __class__ references in 3.3. The first step in this is unwinding the name change for the closure reference so it goes back to using "__class__" (instead of "@__class__") before finding a different way to fix #12370. As near as I can tell, my efforts are getting killed by the frozen instance of importlib: if I make the change in the straightforward fashion, the frozen copy of FindLoader.load_module() uses zero-argument super(), which tries to look up "@__class__", which fails, which means initialisation goes pear-shaped. I'm going to fix it in this case by tweaking importlib._bootstrap to avoid using zero-argument super() (with an unmodified core) before applying the changes, but yeah, be warned that you're in for some fun when tinkering with any construct used by importlib._bootstrap and end up doing something that involves changing the PYC magic number. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 4

Re: [Python-Dev] cpython: Addressed some buildbot errors and comments on the checkin by Antoine on
by Antoine Pitrou 26 May '12

26 May '12

On Sat, 26 May 2012 21:39:36 +0200 vinay.sajip <python-checkins(a)python.org> wrote: > return False > _sys_home = getattr(sys, '_home', None) > -if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'): > +if _sys_home and os.name == 'nt' and \ > + _sys_home.lower().endswith(('pcbuild', 'pcbuild\\amd64')): > _sys_home = os.path.dirname(_sys_home) Ok, but is one os.path.dirname() call enough in the AMD64 case? It looks like you'd want to walk up two directories rather than one (but I might misunderstand). Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] cpython: issue 14660: Implement PEP 420, namespace packages.
by Barry Warsaw 26 May '12

26 May '12

On May 25, 2012, at 10:31 AM, Brett Cannon wrote: >Is documentation coming in a separate commit? Yes. I've been reworking the import machinery documentation; it's a work-in-progress on the pep-420 feature clone ('importdocs' branch). I made some good progress and then got side-tracked, but I'm planning on getting back to it soon. -Barry

2 1