Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> It probably wouldn't be very difficult to make element_new() the tp_new > of Element_Type, and expose that type as "Element". > That would settle the issue nicely and avoid compatibility concerns :) > > Regards > I guess it's not as simple as that. element_new doesn't quite have the signature re

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 22, 2012 at 04:24:38AM +0200, Eli Bendersky wrote: > > Andrew, could you elaborate on your use case? Are you using cElementTree to > do the parsing, or ElementTree (the Python implementation). Can you show a > short code sample? I'm mostly using ElementTree because several classes/fun

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Thanks for describing the use case. By the way, when working with ET I also wanted to track the memory usage of the package a couple of times, which made me lament that there's no useful memory profiler in the stdlib. A memory profiler can be a ten-line Python function which, however, does need

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> > I can't fathom why someone would do it though, since bar tiny > > differences (like this one) cET is just a faster ET and it's available > > practically everywhere with CPython. I mean, is it really important to > > be able to subclass ET.Element? What goal does it serve? > > Statements like th

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> I'm happy to stand up as an example of someone who uses a custom Element > class. My specific use case is loading the project Gutenberg database, > which is a 210MB XML file. I created a custom Element class which I use > for the top-level element (a custom element_factory passed to > TreeBuild

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 22, 2012 at 8:16 AM, Andrew McNabb wrote: > So, I would be one of those people who would flood in the complaints. :) As another "you don't know what you're going to break" war story: In Python 2.5, using "-m" with a package appeared to work, but actually slightly corrupted the import

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 21, 2012 at 10:47:43PM +0100, "Martin v. Löwis" wrote: > > I can't fathom why someone would do it though, since bar tiny > > differences (like this one) cET is just a faster ET and it's available > > practically everywhere with CPython. I mean, is it really important to > > be able to s

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 22, 2012 at 7:47 AM, "Martin v. Löwis" wrote: > Am 21.02.2012 11:41, schrieb Eli Bendersky: >> I can't fathom why someone would do it though, since bar tiny >> differences (like this one) cET is just a faster ET and it's available >> practically everywhere with CPython. I mean, is it r

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, 21 Feb 2012 12:41:17 +0200 Eli Bendersky wrote: > On Tue, Feb 21, 2012 at 03:59, Nick Coghlan wrote: > > > On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky wrote: > > > So the two choices here are either change the documentation or the C > > > implementation to actually make Element a cl

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Am 21.02.2012 11:41, schrieb Eli Bendersky: > > > On Tue, Feb 21, 2012 at 03:59, Nick Coghlan > wrote: > > On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky > wrote: > > So the two choices here are either change the documentation or

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 21, 2012 at 03:59, Nick Coghlan wrote: > On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky wrote: > > So the two choices here are either change the documentation or the C > > implementation to actually make Element a class. The first is of course > > simpler. However, someone somewhere

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky wrote: > So the two choices here are either change the documentation or the C > implementation to actually make Element a class. The first is of course > simpler. However, someone somewhere may have written code that knowingly > forces the Python imp

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 21, 2012 at 00:51, Nick Coghlan wrote: > On Tue, Feb 21, 2012 at 1:55 AM, wrote: > >> Basically, if something is just documented as being callable without > >> subclassing or instance checks being mentioned as supported in the > >> docs, it can be implemented as either a type or an

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 21, 2012 at 1:55 AM, wrote: >> Basically, if something is just documented as being callable without >> subclassing or instance checks being mentioned as supported in the >> docs, it can be implemented as either a type or an ordinary function, >> or pretty much any other kind of callab

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Basically, if something is just documented as being callable without subclassing or instance checks being mentioned as supported in the docs, it can be implemented as either a type or an ordinary function, or pretty much any other kind of callable without being deemed an API change So what would

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Mon, Feb 20, 2012 at 9:43 PM, Xavier Morel wrote: > I'm not sure that's much of an issue, Element (and most of the top-level > utility "constructors") are documented as being frontend interfaces with > no specific type of their own, and indeed they are simply functions in > lxml, just as they a

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 2012-02-20, at 12:36 , Eli Bendersky wrote: > On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis" wrote: > >>> The change of backing ElementTree by cElementTree has already been >>> implemented in the default branch (3.3) by Florent Xicluna with careful >>> review from me and others. etree has an

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis" wrote: > > The change of backing ElementTree by cElementTree has already been > > implemented in the default branch (3.3) by Florent Xicluna with careful > > review from me and others. etree has an extensive (albeit a bit clumsy) > > set of tests w

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> The change of backing ElementTree by cElementTree has already been > implemented in the default branch (3.3) by Florent Xicluna with careful > review from me and others. etree has an extensive (albeit a bit clumsy) > set of tests which keep passing successfully after the change. I just noticed

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 18/02/2012 0.04, Nick Coghlan wrote: On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melotti wrote: I'm assuming that eventually the module will be removed (maybe for Python 4?), and I don't expect nor want to seen it removed in the near future. If something gets removed it should be deprecated first,

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melotti wrote: > I'm assuming that eventually the module will be removed (maybe for Python > 4?), and I don't expect nor want to seen it removed in the near future. > If something gets removed it should be deprecated first, and it's usually > better to depreca

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 17 February 2012 04:55, Antoine Pitrou wrote: > But then you're going from a cumbersome situation (where you have to > import cElementTree and then fallback on regular ElementTree) to an > even more cumbersome one (where you have to first check the Python > version, then conditionally import c

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 16/02/2012 19.55, Antoine Pitrou wrote: On Thu, 16 Feb 2012 19:32:24 +0200 Ezio Melotti wrote: If I'm writing code that imports cElementTree on 3.3+, and I explicitly turn on DeprecationWarnings (that would otherwise be silenced) to check if I'm doing something wrong, I would like Python to

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

I personally don't see any reason to drop a module that isn't terminally broken or unmaintainable, apart from scaring users away by making them think that we don't care about backward compatibility. ___ Python-Dev mailing list Python-Dev@python.org http:/

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Thu, 16 Feb 2012 19:32:24 +0200 Ezio Melotti wrote: > > If I'm writing code that imports cElementTree on 3.3+, and I explicitly > turn on DeprecationWarnings (that would otherwise be silenced) to check > if I'm doing something wrong, I would like Python to tell me "You don't > need to impor

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 14/02/2012 9.58, Stefan Behnel wrote: Nick Coghlan, 14.02.2012 05:44: On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: With the deprecation warning being silent, is there much to lose, though? Yes, it creates problems for anyone that deliberately converts all warnings to errors when ru

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> I'd still like to know who is in charge of the etree package now. I know > that I'm not, so I just don't have any opinion on the technical question > of using the accelerator module (it sounds like a reasonable idea, but > it also sounds like something that may break existing code). If the > main

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> Does this imply that each and every package in the stdlib currently > has a dedicated maintainer who promised to be dedicated to it? Or > otherwise, should those packages that *don't* have a maintainer be > removed from the standard library? That is my opinion, yes. Some people (including myself

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> So, getting back to the topic again, is there any reason why you would > oppose backing the ElementTree module in the stdlib by cElementTree's > accelerator module? Or can we just consider this part of the discussion > settled and start getting work done? I'd still like to know who is in charge

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Thu, Feb 16, 2012 at 1:40 PM, Philip Jenvey wrote: > What about a PendingDeprecationWarning? I think you're usually only going to > convert DeprecationWarnings to errors (with python -W > error::DeprecationWarning or warnings.simplefilter('error', > DeprecationWarning)) Think "-Wall" for st

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Feb 13, 2012, at 8:44 PM, Nick Coghlan wrote: > On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: >> With the deprecation warning being silent, is there much to lose, though? > > Yes, it creates problems for anyone that deliberately converts all > warnings to errors when running their te

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Le 14/02/2012 08:58, Stefan Behnel a écrit : > I'm -1 on emitting a deprecation warning just because cElementTree is being > replaced by a bare import. That's an implementation detail, just like > cElementTree should have been an implementation detail in the first place. > In all currently maintain

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Mon, Feb 13, 2012 at 23:16, Nick Coghlan wrote: > On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote: > > An open question remains on whether to deprecate cElementTree, now that > this > > change is in place. > > > > Currently in 3.3 the whole cElementTree module is: > > > > # Deprecated

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 2012-02-14, at 08:58 , Stefan Behnel wrote: > > These days, other Python implementations already provide the cElementTree > module as a bare alias for ElementTree.py anyway, without emitting any > warnings. Why should CPython be the only one that shouts at users for > importing it? Since all w

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Nick Coghlan, 14.02.2012 05:44: > On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: >> With the deprecation warning being silent, is there much to lose, though? > > Yes, it creates problems for anyone that deliberately converts all > warnings to errors when running their test suites. This forc

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: > With the deprecation warning being silent, is there much to lose, though? Yes, it creates problems for anyone that deliberately converts all warnings to errors when running their test suites. This forces them to spend time switching over to

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> Currently in 3.3 the whole cElementTree module is: > > > > # Deprecated alias for xml.etree.ElementTree > > > > from xml.etree.ElementTree import * > > > > Would it be alright to issue a DeprecationWarning if this module is > > imported? Then hopefully a couple of releases after 3.3 we can j

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote: > An open question remains on whether to deprecate cElementTree, now that this > change is in place. > > Currently in 3.3 the whole cElementTree module is: > >   # Deprecated alias for xml.etree.ElementTree > >   from xml.etree.ElementTree impo

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> > The change was committed to the default branch. In 3.3, "import > xml.etree.ElementTree" will automatically use the _elementtree accelerator, > if available, and will fall back to a Python implementation otherwise. The > documentation of ElementTree has also been updated to reflect this fact. >

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 13.02.2012 12:35: >> Since there appeared to be an overall positive response for making >> this change in Python 3.3, and since there isn't longer any doubt >> about the ownership of the package *in Python's stdlib* (see >> http://mail.python.org/pipermail/python-dev/2012-February/11

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> Since there appeared to be an overall positive response for making > this change in Python 3.3, and since there isn't longer any doubt > about the ownership of the package *in Python's stdlib* (see > http://mail.python.org/pipermail/python-dev/2012-February/116389.html), > I've opened issue 13988

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> """A common pattern in Python 2.x is to have one version of a module > implemented in pure Python, with an optional accelerated version > implemented as a C extension; for example, pickle and cPickle. This > places the burden of importing the accelerated version and falling > back on the pure Py

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

2012/2/10 Nick Coghlan : > > Most orphan modules in the stdlib aren't like that - yes, their APIs > stagnate (because nobody feels they have the authority and/or > expertise to make potentially controversial decisions), but for many > of them, that's not a particularly bad thing. You're right, and

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Fri, Feb 10, 2012 at 7:37 PM, "Martin v. Löwis" wrote: > Notice that the last time something like this came up (bsddb), it > actually resulted in a removal of the respective package from the > standard library. bsddb was a *very* different case - it was actively causing buildbot stability prob

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

"Martin v. Löwis", 10.02.2012 11:32: >> What happens now? Do we give up on touching it until Fredrik Lundh >> decides on a come-back or some person who is willing to commit 5 years >> is found? Or do we just *keep* maintaining it in the stdlib as we do >> with other modules, fixing bugs, tests, doc

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

>> What happens now? Do we give up on touching it until Fredrik Lundh >> decides on a come-back or some person who is willing to commit 5 years >> is found? Or do we just *keep* maintaining it in the stdlib as we do >> with other modules, fixing bugs, tests, documentation and so on? > > If we reall

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

"Martin v. Löwis", 10.02.2012 10:37: >> Given that it was two months ago that I started the "Fixing the XML >> batteries" thread (and years since I brought up the topic for the first >> time), it seems to be hard enough already to get anyone on python-dev >> actually do something for Python's XML s

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> How does this differ from any other module in stdlib that may not have > a single designated owner, but which at the same time *is* being > maintained by the core developers as a group? ISTM that requiring a > five-year commitment is just going to scare any contributors away - is > that what we w

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Fri, Feb 10, 2012 at 11:43, "Martin v. Löwis" wrote: >> IMHO it's no longer a question of "wanting" to take ownership. >> According to Florent, this has already happened to some extent. > > "Ownership to some extent" is not a useful concept. Either you have > ownership, or you don't. > >> I don

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 10.02.2012 10:06: > On Fri, Feb 10, 2012 at 10:32, Florent wrote: >> 2012/2/10 Eli Bendersky >>> >>> Thanks for the input, Florent. So, to paraphrase, there already are >>> code changes in the stdlib version of ET/cET which are not upstream. >>> You made it explicit about the te

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> IMHO it's no longer a question of "wanting" to take ownership. > According to Florent, this has already happened to some extent. "Ownership to some extent" is not a useful concept. Either you have ownership, or you don't. > I don't mind sending Fredrik an email as you detailed. Any suggested >

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

> That makes me consider it the reality that "today, ET is only being > maintained in the stdlib". I think different people will have different perceptions of reality here. In my interaction with Fredrik Lundh, I got the impression that he might consider code still maintained even if he didn't to

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Fri, Feb 10, 2012 at 10:32, Florent wrote: > 2012/2/10 Eli Bendersky >> > >> >> Thanks for the input, Florent. So, to paraphrase, there already are >> code changes in the stdlib version of ET/cET which are not upstream. >> You made it explicit about the tests, so the question is only left for

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

2012/2/10 Eli Bendersky > > > > Thanks for the input, Florent. So, to paraphrase, there already are > code changes in the stdlib version of ET/cET which are not upstream. > You made it explicit about the tests, so the question is only left for > the modules themselves. Is that right? > The port o

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

>> That said, I think that the particular change discussed in this thread >> can be made anyway, since it doesn't really modify ET's APIs or >> functionality, just the way it gets imported from stdlib. > > I would suggest that, assuming python-dev want to take ownership of > the module, one last-di

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

>> On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou >> wrote:> >> > It's not frozen, it's actually maintained. >> >> Indeed, it sounds like the most appropriate course (if we don't hear >> otherwise from Fredrik) may be to just update PEP 360 to acknowledge >> current reality (i.e. the most current

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

2012/2/8 Nick Coghlan > On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou > wrote:> > > It's not frozen, it's actually maintained. > > Indeed, it sounds like the most appropriate course (if we don't hear > otherwise from Fredrik) may be to just update PEP 360 to acknowledge > current reality (i.e.

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Paul Moore wrote: I would suggest that, assuming python-dev want to take ownership of the module, one last-ditch attempt be made to contact Fredrik. We should email him, I wouldn't call email to be "last-ditch". I call email "first-ditch". I would expect that a last-ditch attempt would includ

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 8 February 2012 12:21, Nick Coghlan wrote: > On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou wrote: >> On Wed, 8 Feb 2012 11:11:07 + >> Paul Moore wrote: >>> It's important to respect Fredrik's wishes and ownership, but we can't >>> leave part of the stdlib frozen and abandoned just becau

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

>> It's not frozen, it's actually maintained. > > Indeed, it sounds like the most appropriate course (if we don't hear > otherwise from Fredrik) may be to just update PEP 360 to acknowledge > current reality (i.e. the most current release of ElementTree is > actually the one maintained by Florent i

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou wrote: > On Wed, 8 Feb 2012 11:11:07 + > Paul Moore wrote: >> It's important to respect Fredrik's wishes and ownership, but we can't >> leave part of the stdlib frozen and abandoned just because he's not >> available any longer. > > It's not fro

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, 8 Feb 2012 11:11:07 + Paul Moore wrote: > On 8 February 2012 09:49, Eli Bendersky wrote: > >> I concur. It's important that we consider Fredrik's ownership of the > >> modules, but if he fails to reply to email and doesn't update his > >> repositories, there should be enough cause for

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On 8 February 2012 09:49, Eli Bendersky wrote: >> I concur. It's important that we consider Fredrik's ownership of the >> modules, but if he fails to reply to email and doesn't update his >> repositories, there should be enough cause for python-dev to go on and >> appropriate the stdlib versions o

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 11:36, Dirkjan Ochtman wrote: > On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote: >> I didn't get a response from him to my e-mails since early 2010. Maybe >> others have more luck if they try, but I don't have the impression that >> waiting another two years gets us anywh

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote: > I didn't get a response from him to my e-mails since early 2010. Maybe > others have more luck if they try, but I don't have the impression that > waiting another two years gets us anywhere interesting. > > Given that it was two months ago that

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Fred Drake, 08.02.2012 05:41: > On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote: >> Besides, in >> http://mail.python.org/pipermail/python-dev/2011-December/114812.html >> Stefan Behnel said "[...] Today, ET is *only* being maintained in the >> stdlib by Florent Xicluna [...]". Is this not tr

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

>> The facade can be added to xml/etree/ElementTree.py since that's the >> only documented module. It can attempt to do: >> >> from _elementtree import * >> >> (which is what cElementTree.py) does, and on failure, just go on doing >> what it does now. > > Basically, cElementTree (actually the accel

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 08.02.2012 07:07: > On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote: >> On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote: >>> The initial proposal of changing *the stdlib >>> import facade* for xml.etree.ElementTree to use the C accelerator >>> (_elementtree) by default. >> >> I g

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote: > On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote: >> The initial proposal of changing *the stdlib >> import facade* for xml.etree.ElementTree to use the C accelerator >> (_elementtree) by default. > > I guess this is one source of confusion: w

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote: > The initial proposal of changing *the stdlib > import facade* for xml.etree.ElementTree to use the C accelerator > (_elementtree) by default. I guess this is one source of confusion: what are you referring to an an "import façade"? When I l

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 06:41, Fred Drake wrote: > On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote: >> Besides, in >> http://mail.python.org/pipermail/python-dev/2011-December/114812.html >> Stefan Behnel said "[...] Today, ET is *only* being maintained in the >> stdlib by Florent Xicluna [.

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote: > Besides, in > http://mail.python.org/pipermail/python-dev/2011-December/114812.html > Stefan Behnel said "[...] Today, ET is *only* being maintained in the > stdlib by Florent Xicluna [...]". Is this not true? I don't know. I took this to

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 06:15, Nick Coghlan wrote: > On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky wrote: >> Is there a good reason why xml.etree.ElementTree / >> xml.etree.cElementTree did not "receive this treatment"? > > See PEP 360, which lists "Externally Maintained Packages". In the past > w

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Tue, Feb 7, 2012 at 22:15, Nick Coghlan wrote: > Folding the two > implementations together in the standard library would mean officially > declaring that xml.etree is now an independently maintained fork of > Fredrik's version rather than just a "snapshot in time" of a > particular version (wh

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky wrote: > Is there a good reason why xml.etree.ElementTree / > xml.etree.cElementTree did not "receive this treatment"? See PEP 360, which lists "Externally Maintained Packages". In the past we allowed additions to the standard library without requirin

[Python-Dev] folding cElementTree behind ElementTree in 3.3

Hello, Here's a note from "What's new in Python 3.0": """A common pattern in Python 2.x is to have one version of a module implemented in pure Python, with an optional accelerated version implemented as a C extension; for example, pickle and cPickle. This places the burden of importing the accele