Mailman 3 February 2012 - Python-Dev

Summary of Python tracker Issues
by Python tracker Feb. 10, 2012

Feb. 10, 2012

ACTIVITY SUMMARY (2012-02-03 - 2012-02-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 3246 ( -2) closed 22523 (+57) total 25769 (+55) Open issues with patches: 1394 Issues opened (36) ================== #13929: fnmatch to support escape characters http://bugs.python.org/issue13929 reopened by terry.reedy #13934: sqlite3 test typo http://bugs.… [View More]

1 0

maintenance of the ElementTree / cElementTree packages in the Python standard library
by Eli Bendersky Feb. 10, 2012

Feb. 10, 2012

Hello Fredrik, Recently a discussion came up on the python-dev mailing list regarding continued maintenance of the ElementTree & cElementTree packages which are part of the standard library, and which were originally contributed by you. There currently exists an unclear situation with respect to the active maintainer(s) of these packages. On one hand, PEP 360 states that the packages are officially maintained in your repositories and all problems should be assigned to you and fixed … [View More]

1 0

patch
by Victor Stinner Feb. 9, 2012

Feb. 9, 2012

1 0

Re: [Python-Dev] [Python-checkins] cpython: PEP 410
by Nick Coghlan Feb. 9, 2012

Feb. 9, 2012

On Thu, Feb 9, 2012 at 7:52 AM, victor.stinner <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/f8409b3d6449 > changeset: 74832:f8409b3d6449 > user: Victor Stinner <victor.stinner(a)haypocalc.com> > date: Wed Feb 08 14:31:50 2012 +0100 > summary: > PEP 410 Ah, even when written by a core dev, a PEP should still be at Accepted before we check anything in. PEP 410 is still at … [View More]

2 3

ctypes/utils.py problem
by David Goulet Feb. 8, 2012

Feb. 8, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, I'm working with the LTTng (Linux Tracing) team and we came across a problem with our user-space tracer and Python default behavior. We provide a libc wrapper that instrument free() and malloc() with a simple ld_preload of that lib. This lib *was* named "liblttng-ust-libc.so" and we came across python software registering to our trace registry daemon (meaning that somehow the python binary is using our in-process library). We dig a … [View More]

2 1

Re: [Python-Dev] which C language standard CPython must conform to
by Gregory P. Smith Feb. 8, 2012

Feb. 8, 2012

On Tue, Feb 7, 2012 at 1:41 PM, "Martin v. Löwis" <martin(a)v.loewis.de> wrote: > Am 07.02.2012 20:10, schrieb Gregory P. Smith: >> Why do we still care about C89? It is 2012 and we're talking about >> Python 3. What compiler on what platform that anyone actually cares >> about does not support C99? > > As Amaury says: Visual Studio still doesn't support C99. The story is > both funny and sad: In Visual Studio 2002, the release notes included > … [View More]

2 1

Code review tool uses my old email address
by Mark Shannon Feb. 8, 2012

Feb. 8, 2012

Hi, I changed my email address (about a year ago) and updated my bug tracker settings to my new address (late last year). However, the code review tool still shows my old email address. How do I change it? Cheers, Mark.

2 1

Re: [Python-Dev] [Python-checkins] Daily reference leaks (140f7de4d2a5): sum=888
by Nick Coghlan Feb. 8, 2012

Feb. 8, 2012

On Tue, Feb 7, 2012 at 2:34 PM, <solipsis(a)pitrou.net> wrote: > results for 140f7de4d2a5 on branch "default" > -------------------------------------------- > > test_capi leaked [296, 296, 296] references, sum=888 This appears to have started shortly after Benjamin's _PyExc_Init bltinmod refcounting change to fix Brett's crash when bootstrapping importlib. Perhaps we have a leak in import.c that was being masked by the DECREF in _PyExc_Init? Cheers, Nick. -- Nick Coghlan&… [View More]

2 1

Fixing the XML batteries
by Stefan Behnel Feb. 7, 2012

Feb. 7, 2012

Hi everyone, I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. Note upfront: you may or may not know me as the maintainer of lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post was triggered by the following kind of conversation that I keep having with new XML users in Python (mostly on c.l.py), which hints at some serious flaw in the stdlib. User: I'm trying to do XML stuff XYZ in Python and have problem ABC. Me: What library are … [View More]you using? Could you show us some code? User: My code looks like this snippet: ... Me: You are using minidom which is known to be hard to use, slow and uses lots of memory. Use the xml.etree.ElementTree package instead, or rather its C implementation cElementTree, also in the stdlib. User (coming back after a while): thanks, that was exactly what [I didn't know] I was looking for. What does this tell us? 1) MiniDOM is what new users find first. It's highly visible because there are still lots of ancient "Python and XML" web pages out there that date back from the time before Python 2.5 (or rather something like 2.2), when it was the only XML tree library in the stdlib. It's also the first hit from the top when you search for "XML" on the stdlib docs page and contains the (to some people) familiar word "DOM", which lets users stop their search and start writing code, not expecting to find a separate alternative in the same stdlib, way further down. And the description as "mini", "simple" and "lightweight" suggests to users that it's going to be easy to use and efficient. 2) MiniDOM is not what users want. It leads to complicated, unpythonic code and lots of problems. It is neither easy to use, nor efficient, nor "lightweight", "simple" or "mini", not in absolute numbers (see http://bugs.python.org/issue11379#msg148584 and following for a recent discussion). It's also badly maintained in the sense that its performance characteristics could likely be improved, but no-one is seriously interested in doing that, because it would not lead to something that actually *is* fast or memory friendly compared to any of the 'real' alternatives that are available right now. 3) ElementTree is what users should use, MiniDOM is not. ElementTree was added to the stdlib in Py2.5 on popular demand, exactly because it is very easy to use, very fast, and very memory friendly. And because users did not want to use MiniDOM any more. Today, ElementTree has a rather straight upgrade path towards lxml.etree if more XML features like validation or XSLT are needed. MiniDOM has nothing like that to offer. It's a dead end. 4) In the stdlib, cElementTree is independent of ElementTree, but totally hidden in the documentation. In conversations like the above, it's unnecessarily complex to explain to users that there is ElementTree (which is documented in the stdlib), but that what they want to use is really cElementTree, which has the same API but does not have a stdlib documentation page that I can send them to. Note that the other Python implementations simply provide cElementTree as an alias for ElementTree. That leaves CPython as the only Python implementation that really has these two separate modules. So, there are many problems here. And I think they make it unnecessarily complicated for users to process XML in Python and that the current situation helps in turning away new users from Python as a language for XML processing. Python does have impressively great tools for working with XML. It's just that the stdlib and its documentation do not reflect or even appreciate that. What should change? a) The stdlib documentation should help users to choose the right tool right from the start. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. I created a ticket (issue11379) for a minor step in this direction, but given the responses, I'm rather convinced that there's a lot more that can be done and should be done, and that it should be done now, right for the next release. b) cElementTree should finally loose it's "special" status as a separate library and disappear as an accelerator module behind ElementTree. This has been suggested a couple of times already, and AFAIR, there was some opposition because 1) ET was maintained outside of the stdlib and 2) the APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2 was a U-turn. Today, ET is *only* being maintained in the stdlib by Florent Xicluna (who is doing a good job with it), and ET 1.3 has basically made the APIs of both implementations compatible again. So, 3.3 would be the right milestone for fixing the "two libs for one" quirk. Given that this is the third time during the last couple of years that I'm suggesting to finally fix the stdlib and its documentation, I won't provide any further patches before it has finally been accepted that a) this is a problem and b) it should be fixed, thus allowing the patches to actually serve a purpose. If we can agree on that, I'll happily help in making this change happen. Stefan [View Less]

18 46

Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings
by Jim Jewett Feb. 7, 2012

Feb. 7, 2012

I realize that _Py_Identifier is a private name, and that PEP 3131 requires anything (except test cases) in the standard library to stick with ASCII ... but somehow, that feels like too long of a chain. I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier, or at least a comment stating that Identifiers will (per PEP 3131) always be ASCII -- preferably with an assert to back that up. -jJ On Sat, Feb 4, 2012 at 7:46 PM, victor.stinner <python-checkins(a)python.org> wrote: … [View More]

7 10