http://blog.gmane.org/gmane.comp.python.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.devel/132850 <pre> 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: 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: 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: 'S</pre> Antoine Pitrou 2012-05-26T19:28:51 http://comments.gmane.org/gmane.comp.python.devel/132845 <pre>I think that I will make a browser in Official Python (not MacPorts Python). What should I do in order to install Webkit for Official Python (not MacPorts Python) ? from tokyo Japan. </pre> Mr.T Beppu 2012-05-26T12:42:23 http://comments.gmane.org/gmane.comp.python.devel/132833 <pre>As some have probably noticed: I updated the Rietveld version that we use to the current code base. There have been a few incompatible changes (schema, GAE API) which I hope I resolved. If you find new problems, please report them to the meta tracker. Regards, Martin </pre> martin< at >v.loewis.de 2012-05-25T17:57:51 http://comments.gmane.org/gmane.comp.python.devel/132830 <pre>I'd like to make a slight doc change for weakref to state (more or less): weakrefs are not invalidated when the strong refs are gone, but rather when garbage collection reclaims the object Should this be accurate for all implementations, or should it be more along the lines of: weakrefs may be invalidated as soon as the strong refs are gone, but may last until garbage collection reclaims the object ~Ethan~ </pre> Ethan Furman 2012-05-25T17:21:39 http://comments.gmane.org/gmane.comp.python.devel/132826 <pre> ACTIVITY SUMMARY (2012-05-18 - 2012-05-25) 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 3440 ( +8) closed 23254 (+58) total 26694 (+66) Open issues with patches: 1455 Issues opened (44) ================== #11804: expat parser not xml 1.1 (breaks xmlrpclib) http://bugs.python.org/issue11804 reopened by xrg #14852: json and ElementTree parsers misbehave on streams containing m http://bugs.python.org/issue14852 opened by Frederick.Ross #14853: test_file.py depends on sys.stdin being unseekable http://bugs.python.org/issue14853 opened by gregory.p.smith #14854: faulthandler: fatal error with "SystemError: null argument to http://bugs.python.org/issue14854 opened by zbysz #14855: IPv6 support for logging.handlers http://bugs.python.org/issue14855 opened by cblp #14856: argparse: creating an already defined subparsers does not rais http://bugs.python.org</pre> Python tracker 2012-05-25T16:07:06 http://comments.gmane.org/gmane.comp.python.devel/132819 <pre>As the latest round of updates that Carl and Vinay pushed to the PEPs repo have addressed my few remaining questions, I am accepting PEP 405 for inclusion in Python 3.3. Thanks to all involved in working out the spec for what to model directly on virtualenv, and areas where cleaner solutions could be found given the power to tweak the behaviour of the core interpreter and the standard library. Cheers, Nick. </pre> Nick Coghlan 2012-05-25T08:44:14 http://comments.gmane.org/gmane.comp.python.devel/132816 <pre>The free Visual Studio 11 Express for Windows 8 (still in beta) will produce both 32 and 64 bit binaries and allow multiple languages but will only produce Metro apps. For desktop apps, either the paid Visual Studio versions or the free 2010 Express releases are required. https://www.microsoft.com/visualstudio/11/en-us/products/express bottom of page. Will this inhibit someday moving to Visual Studio 11 Professional or would VS2010 Express or VC++2010 Express still work for hacking on Python or making extensions that would work with any VS11-produced binary? </pre> Terry Reedy 2012-05-24T22:21:33 http://comments.gmane.org/gmane.comp.python.devel/132804 <pre>Hello all. I seem to be encountering somewhat rare an infinite loop in hash table probing while importing _socket, as triggered by init_socket.c in Python 2.6, as seen/patched shipped with Ubuntu 10.04 LTS. The problem only reproduces on 32 bit machines, on both -O2 and -O0 builds (which is how I have managed to retrieve the detailed stack traces below). To cut to the chase, the bottom of the stack trace invariably looks like this, in particular the "key" (and therefore "hash") value is always the same: #0 0x08088637 in lookdict_string (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203) at ../Objects/dictobject.c:421 #1 0x080886cd in insertdict (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203, value=20) at ../Objects/dictobject.c:450 #2 0x08088cac in PyDict_SetItem (op=&lt;unknown at remote 0x37&gt;, key= 'SO_RCVTIMEO', value=20) at ../Objects/dictobject.c:701 #3 0x0808b8d4 in PyDict_SetItemString (v= {'AF_INET6': 10, 'SocketType': &lt;type at remote 0x8275e00&gt;, 'getaddrinfo': &lt;built-in function</pre> Daniel Farina 2012-05-24T19:11:58 http://comments.gmane.org/gmane.comp.python.devel/132798 <pre> Mingw32CCompiler in cygwincompiler.py emits the symbol -mno-cygwin. This is used to make Cygwin's gcc behave as mingw. As of gcc 4.6 it is not recognized by the mingw gcc compiler itself, and causes as crash. It should be removed because it is never needed for mingw (in any version), only for cross-compilation to mingw from other gcc versions. Instead, those who use CygwinCCompiler or Linux GCC to "cross-compile" to plain Win32 can set -mno-cygwin manually. It also means -mcygwin should be removed from the output of CygwinCCompiler. I think... Sturla </pre> Sturla Molden 2012-05-24T12:03:00 http://comments.gmane.org/gmane.comp.python.devel/132790 <pre>I want to install python db2 package for Python but Im unable to install it. I have installed the easy_install and Im able to successfully import the easy_install. My easy_install location :c:/python27/lib/site-packages/ My db2 egg location c:/python27/ibm_db-1.0.5-py2.7-win32.egg How would my installation command look like in the shell, I tried this command and it gives me invalid error, C:\Python27\Scripts&gt;easy_install c:/python27/lib/site-packages/ibm_db-1.0.5-py2. 7-win32.egg error: Not a URL, existing file, or requirement spec: 'c:/python27/lib/site-pack ages/ibm_db-1.0.5-py2.7-win32.egg' </pre> PremAnand Lakshmanan 2012-05-23T23:00:11 http://comments.gmane.org/gmane.comp.python.devel/132784 <pre>Hi, as Antoine pointed out in the corresponding issue (http://bugs.python.org/issue14757#msg160870), measuring/assessing real-world performance of my patch would be interesting. I mentioned that I am not aware of any relevant Python 3 program/application to report numbers for (but guess that the speedups should persist.) Since nobody came up with an answer yet, I figured it would be a good idea to ask everybody on python-dev for suggestions... Regards, --stefan </pre> stefan brunthaler 2012-05-23T18:40:37 http://comments.gmane.org/gmane.comp.python.devel/132757 <pre>I've mentioned this in private to a few folks, with generally positive feedback. I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If there are no objections in the next few days, I'll make it official. Cheers, -Barry </pre> Barry Warsaw 2012-05-21T21:24:09 http://comments.gmane.org/gmane.comp.python.devel/132737 <pre> I am currently working on porting our Linux tool chains to SuSe Enterprise Linux 11 service pack 2 (SLES11SP2). During this process, we noticed an issue due to a change in the sys.platform string. Previously, the string was "linux2" and it has now changed to "linux3". This seems to be due to a change in the kernel version. This causes the ossaudiodev and linuxaudiodev modules to be omitted from the build. I found the relevant code in setup.py: if platform == 'linux2': # Linux-specific modules exts.append( Extension('linuxaudiodev', ['linuxaudiodev.c']) ) else: missing.append('linuxaudiodev') if platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6', 'freebsd7', 'freebsd8'): exts.append( Extension('ossaudiodev', ['ossaudiodev.c']) ) else: missing.append('ossaudiodev') Since neither of these account for "linux3", they are both omitted from the build. I can simply modify the code to i</pre> Wempa, Kristofer 2012-05-21T14:49:23 http://comments.gmane.org/gmane.comp.python.devel/132711 <pre>I have just reviewed PEP 420 (namespace packages) and sent Eric my detailed feedback; most of it is minor or requesting for examples and I'm sure he'll fix it to my satisfaction. Generally speaking the PEP is a beacon if clarity. But I stumbled about one feature that bothers me in its specification and through its lack of rationale. This is the section on Dynamic Path Computation: (http://www.python.org/dev/peps/pep-0420/#dynamic-path-computation). The specification bothers me because it requires in-place modification of sys.path. Does this mean sys.path is no longer a plain list? I'm sure it's going to break things left and right (or at least things will be violating this requirement left and right); there has never been a similar requirement (unlike, e.g., sys.modules, which is relatively well-known for being cached in a C-level global variable). Worse, this apparently affects __path__ variables of namespace packages as well, which are now specified as an unspecified read-only iterable. (I can only guess </pre> Guido van Rossum 2012-05-21T01:33:03 http://comments.gmane.org/gmane.comp.python.devel/132694 <pre>Hi, as our shutil.rmtree() is vulnerable to symlink attacks (see &lt;http://bugs.python.org/issue4489&gt;) I’ve implemented a safe version using os.fwalk() and os.unlinkat() for Python 3.3. Now we face a problem I’d like a broad opinion on: rmtree has a callback hook called `onerror` that that gets called with amongst others the function that caused the error (see &lt;http://docs.python.org/dev/library/shutil.html#shutil.rmtree&gt;). Two of them differ in the new version: os.fwalk() is used instead of os.listdir() and os.unlinkat() instead of os.remove(). The safe version is used transparently if available, so this could potentially break code. Also it would mean that rmtree would behave differently on Linux &amp; OS X for example. I’ve been thinking to "fake" the function names, as they map pretty good anyway. I.e. call onerror with os.listdir if os.fwalk failed and with os.remove instead of os.unlinkat. That could also make sense if some kind soul writes a safe rmtree for Windows or OS X so the function works t</pre> Hynek Schlawack 2012-05-20T11:58:38 http://comments.gmane.org/gmane.comp.python.devel/132687 <pre>PEP 3135 defines the new zero-argument form of super() as implicitly equivalent to super(__class__, &lt;first argument&gt;), and up until 3.2 has behaved accordingly: if you accessed __class__ from inside a method, you would receive a reference to the lexically containing class. In 3.3, that currently doesn't work: you get NameError instead (http://bugs.python.org/issue14857) While the 3.2 behaviour wasn't documented in the language reference, it's *definitely* documented in PEP 3135 (and my recent updates to the 3.3 version of the metaclass docs were written accordingly - that's how I discovered the problem) The error in the alpha releases appears to be a consequence of the attempt to fix a problem where the special treatment of __class__ meant that you couldn't properly set the __class__ attribute of the class itself in the class body (see http://bugs.python.org/issue12370). The fact that patch went in without causing a test failure means that this aspect of PEP 3135 has no explicit tests - it was only teste</pre> Nick Coghlan 2012-05-20T08:51:27 http://comments.gmane.org/gmane.comp.python.devel/132686 <pre>When writing the docs for types.new_class(), I discovered that the description of the class creation process in the language reference was not only hard to follow, it was actually *incorrect* when it came to describing the algorithm for determining the correct metaclass. I rewrote the offending section of the language reference to both describe the correct algorithm, and hopefully also to be easier to read. Once people have had a chance to review the changes in the 3.3 docs, I'll backport the update to 3.2. Previous docs: http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation Updated docs: http://docs.python.org/dev/reference/datamodel.html#customizing-class-creation Cheers, Nick. </pre> Nick Coghlan 2012-05-20T08:38:10 http://comments.gmane.org/gmane.comp.python.devel/132675 <pre>At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Wouldn't this be an easy bit to flip in order to promote Python 3 more better? Cheers, -Barry </pre> Barry Warsaw 2012-05-18T18:24:18 http://comments.gmane.org/gmane.comp.python.devel/132674 <pre> ACTIVITY SUMMARY (2012-05-11 - 2012-05-18) 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 3432 (+14) closed 23196 (+53) total 26628 (+67) Open issues with patches: 1457 Issues opened (52) ================== #14784: Re-importing _warnings changes warnings.filters http://bugs.python.org/issue14784 opened by brett.cannon #14785: Add sys._debugmallocstats() http://bugs.python.org/issue14785 opened by dmalcolm #14787: pkgutil.walk_packages returns extra modules http://bugs.python.org/issue14787 opened by cjerdonek #14788: Pdb debugs itself after ^C and a breakpoint is set anywhere http://bugs.python.org/issue14788 opened by xdegaye #14789: after continue, Pdb stops at a line without a breakpoint http://bugs.python.org/issue14789 opened by xdegaye #14790: use packaging in setup.py http://bugs.python.org/issue14790 opened by pitrou #14791: setup.py only ad</pre> Python tracker 2012-05-18T16:07:12 http://comments.gmane.org/gmane.comp.python.devel/132644 <pre> Hello all, We still need 64-bit Windows buildbots to test for regressions. Otherwise we might let regressions slip through, since few people seem to run the test suite under Windows at home. Regards Antoine. </pre> Antoine Pitrou 2012-05-16T12:44:56 http://comments.gmane.org/gmane.comp.python.devel/132632 <pre>Hi python-dev, these ideas/questions comes out of the Cython and NumPy developer lists. What we want is a way to communicate things on the C level about the extension type instances we pass around. The solution today is often to rely on PyObject_TypeCheck. For instance, hundreds of handcrafted C extensions rely on the internal structure of NumPy arrays, and Cython will check whether objects are instances of a Cython class or not. However, this creates one-to-many situations; only one implementor of an object API/ABI, but many consumers. What we would like is multiple implementors and multiple consumers of mutually agreed-upon standards. We essentially want more duck typing on the C level. A similar situation was PEP 3118. But there's many more such things one might want to communicate at the C level, many of which are very domain-specific and not suitable for a PEP at all. Also PEPs don't backport well to older versions of Python. What we *think* we would like (but we want other suggestions!) </pre> Dag Sverre Seljebotn 2012-05-16T07:44:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.devel