[Python-Dev] ElementTree in stdlib
Catching up on some python-dev email, I was surprised to see that things seem to be barrelling ahead with the adding of ElementTree to Python core without any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of PyXML in order to satsify the demand for a Pythonic databinding+API for XML in stdlib seems to be a bit of a raised middle finger to those folks who have worked hard on competing or differently-scoped APIs, each of which deserves a bit more peer review than just a single nomination on python-dev, which seems to be all it took to obtain a blessing for ElementTree. I have nothing against ElementTree, and would like to see more XML processing options in core, but it seems to me like the XML-SIG is being deliberately left out of this process. Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had been tinkering with.[1] I don't think anyone was really bold enough to tell him what they really thought of it (other than that it is a lot like XIST), but it was admirable that he put it up for peer review rather than just dropping it into stdlib. Perhaps more importantly, it prompted some discussion that more or less acknowledged that these kinds of APIs do seem to be the future of XML in Python, and that we should be thinking about bringing some of them into PyXML and, ultimately, stdlib. But the problem of how to choose from the many options also became immediately apparent.[2] The discussion stalled, but I think it should start up again, in the proper forum, rather than letting the first-mentioned API supplant the dozen+ alternatives that could also be considered as candidates.[3] Sorry to be a sourpuss. Mike -- [1] http://mail.python.org/pipermail/xml-sig/2005-November/011248.html (Guido's very civil proposal and request for peer review) [2] http://mail.python.org/pipermail/xml-sig/2005-November/011252.html (this also summarizes the categories of software/approaches that people are taking to the general problem of working with XML Pythonically) [3] http://www.xml.com/pub/a/2004/10/13/py-xml.html (and there are at least 3 more databinding APIs that have come out since then) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] elementtree in stdlib
A while ago there was some discussion about including elementtree in the std lib. I can't remember what the conclusion about that was, but if it does go ahead, I'd like to suggest that it be reorganised a bit. I've just started playing with it, and having a package called elementtree containing a module called ElementTree containing a class called ElementTree is just too confusing for words! -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
I'm not so surprised that Fredrik chose to bypass XML-SIG. There doesn't seem to be a lot of decision power there -- in fact it feels a bit dead, with a weird mix of too-high-level discussions that don't go anywhere, plus basic beginner's Q+A. Also, it would seem that /F's ElementTree doesn't need much vetting -- it seems well established and well-known in the XML-SIG (it was listed in all the overviews of APIs). Finally, compared offerings based on e.g. 4thought (sp.?), ElementTree feels much more practical and hence, might I say it, "pythonic". --Guido On 12/12/05, Mike Brown <[EMAIL PROTECTED]> wrote: > Catching up on some python-dev email, I was surprised to see that things seem > to be barrelling ahead with the adding of ElementTree to Python core without > any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of > PyXML in order to satsify the demand for a Pythonic databinding+API for XML in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. I have nothing against > ElementTree, and would like to see more XML processing options in core, but it > seems to me like the XML-SIG is being deliberately left out of this process. > > Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had > been tinkering with.[1] I don't think anyone was really bold enough to tell > him what they really thought of it (other than that it is a lot like XIST), > but it was admirable that he put it up for peer review rather than just > dropping it into stdlib. Perhaps more importantly, it prompted some discussion > that more or less acknowledged that these kinds of APIs do seem to be the > future of XML in Python, and that we should be thinking about bringing some of > them into PyXML and, ultimately, stdlib. But the problem of how to choose from > the many options also became immediately apparent.[2] The discussion stalled, > but I think it should start up again, in the proper forum, rather than letting > the first-mentioned API supplant the dozen+ alternatives that could also be > considered as candidates.[3] > > Sorry to be a sourpuss. > > Mike > -- > > [1] http://mail.python.org/pipermail/xml-sig/2005-November/011248.html > (Guido's very civil proposal and request for peer review) > [2] http://mail.python.org/pipermail/xml-sig/2005-November/011252.html (this > also summarizes the categories of software/approaches that people are > taking to the general problem of working with XML Pythonically) > [3] http://www.xml.com/pub/a/2004/10/13/py-xml.html (and there are at least > 3 more databinding APIs that have come out since then) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Mike Brown wrote: > Catching up on some python-dev email, I was surprised to see that things seem > to be barrelling ahead with the adding of ElementTree to Python core without > any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of > PyXML in order to satsify the demand for a Pythonic databinding+API for XML in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. I didn't really feel like the proposal was out of the blue. The proposal has been brought up before, both on python-dev[1] and the python-list[2]. ElementTree has a pretty large following - if you look at XML-based questions on the python-list, I can almost guarantee you that someone will give an elementtree solution to it (and not just Fredrik). I don't know much about any other APIs, so I'm not going to try to claim it's the best API or anything, but it is the best of what seems to have any user visibility on the python-list. [1]http://mail.python.org/pipermail/python-dev/2005-June/054092.html [2]http://mail.python.org/pipermail/python-list/2005-December/314288.html STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Steven Bethard wrote: > I didn't really feel like the proposal was out of the blue. The > proposal has been brought up before, both on python-dev[1] and the > python-list[2]. ElementTree has a pretty large following - if you > look at XML-based questions on the python-list, I can almost guarantee > you that someone will give an elementtree solution to it (and not just > Fredrik). I don't know much about any other APIs, so I'm not going to > try to claim it's the best API or anything, but it is the best of what > seems to have any user visibility on the python-list. It's difficult to establish precise numbers, but I would expect that most readers of xml-sig are well aware of how DOM and SAX work, perhaps even better than ElementTree. My main complaint about this was in the past that it is a Python-only solution, so people working in multiple languages cannot reuse their knowledge. It seems that this is irrelevant, as people don't work in multiple languages so much. I still think that Python should continue to provide standard APIs, for those that know how things are done in Java. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Mike Brown wrote: > Catching up on some python-dev email, I was surprised to see that things seem > to be barrelling ahead with the adding of ElementTree to Python core without > any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of > PyXML in order to satsify the demand for a Pythonic databinding+API for XML > in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. That is not true. The single nomination actually triggered a (admittedly fast) process, where multiple people spoke in favour, not just a single one. It also followed a discussion on python-list. > I have nothing against > ElementTree, and would like to see more XML processing options in core, but > it > seems to me like the XML-SIG is being deliberately left out of this process. I think your impression is wrong (atleast on my part): I did not deliberately side-step xml-sig; it just didn't occur to me to have the discussion there also. I implicitly assumed most people on xml-sig would agree. > Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had > been tinkering with.[1] I don't think anyone was really bold enough to tell > him what they really thought of it (other than that it is a lot like XIST), > but it was admirable that he put it up for peer review rather than just > dropping it into stdlib. Again, your impression is somewhat wrong: Guido first submitted the code to the SF bug tracker; there I commented that he should discuss it on xml-sig. I based this recommendation on my view that any such library should see a wider audience first before being admitted to the core; this library of Guido had (to my knowledge) not been seen by a wider audience. This is unlike ElementTree, which had existed for quite some time, and collected a lot of community feedback. > But the problem of how to choose from > the many options also became immediately apparent.[2] The discussion stalled, > but I think it should start up again, in the proper forum, rather than > letting > the first-mentioned API supplant the dozen+ alternatives that could also be > considered as candidates.[3] Well, this is one of the big problems with XML: there are so many libraries to chose from, for so many different kinds of applications. It took me some time to understand what kind of application Guido's library is targetting - and such an analysis always ends up with saying "It is like X, but has Y instead". In this setting, how should we chose a library? In the last round, it was "let's believe in standards". I personally still believe in standards, but it appears that the Python community views them as too bloated. So as that has more-or-less failed, the next natural approach is "let's believe in the community". For that, two things need to happen: the author of the package must indicate that he would like to see it incorporated, and the users must indicate that they like the package. Both has happened for ElementTree, but I think it could happen for other packages, as well. If it is merely the lack of due process you are complaining about, and you agree with the result, then IMO nothing would need to be changed about the result. Discussing it post-factum on xml-sig might still be valuable. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Martin v. Löwis wrote: > Steven Bethard wrote: > > I didn't really feel like the proposal was out of the blue. The > > proposal has been brought up before, both on python-dev[1] and the > > python-list[2]. ElementTree has a pretty large following - if you > > look at XML-based questions on the python-list, I can almost guarantee > > you that someone will give an elementtree solution to it (and not just > > Fredrik). I don't know much about any other APIs, so I'm not going to > > try to claim it's the best API or anything, but it is the best of what > > seems to have any user visibility on the python-list. > > It's difficult to establish precise numbers, but I would expect that > most readers of xml-sig are well aware of how DOM and SAX work, perhaps > even better than ElementTree. Sorry, I didn't mean to imply that DOM and SAX (though mainly DOM in my experience) solutions weren't also offered on the python-list. It's just that we already have DOM and SAX APIs in the stdlib. My point was mainly that elementtree was the xml module that I've seen most often cited on python-list that isn't already in the stdlib. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
> The single nomination actually triggered a (admittedly > fast) process, where multiple people spoke in favour, not just a single > one. It also followed a discussion on python-list. Also, there were silent +1 votes from people like me who followed all the posts and saw no need to alter the direction of the discussion. FWIW, I've been hoping for this for a long time. In retrospect, CCing the XML list would have been nice but I don't think it would have changed the outcome. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
"Martin v. L> So as that has more-or-less failed, the next natural approach is > "let's believe in the community". For that, two things need to > happen: the author of the package must indicate that he would like > to see it incorporated, and the users must indicate that they like > the package. Both has happened for ElementTree, but I think it > could happen for other packages, as well. > > If it is merely the lack of due process you are complaining about, > and you agree with the result, then IMO nothing would need to be > changed about the result. Discussing it post-factum on xml-sig > might still be valuable. Thanks Martin and others for responding. I full agree that ElementTree has proven to be useful, popular, and stable, and probably no one would object to ElementTree being given the endorsement that is implicit in its being made a part of stdlib. The lack of due process, given that XML-SIG seems to exist largely to provide that very service for all things XML in Python, is indeed all I'm complaining about. I am happy that for once, there is momentum behind this sort of thing, and more power to you for that. My fears are just that 1. XML-SIG is being seen as either irrelevant or as an obstacle (perhaps due to the friction between Fredrik and Uche) and are thus being sidestepped, and 2. other libs that could/should be contenders (Amara and 4Suite are not in this list, by the way) are going to become further marginalized by virtue of the fact that people will say "well, we have ElementTree in stdlib already, why do we need (fill in the blank)?" I suppose the same kind of implicit endorsements were given to minidom and SAX, and that obviously hasn't prevented people from going out and using ElementTree, lxml, etc., so I don't know... I can't predict the future. I'd just feel better about it if everyone on XML-SIG, where people hang out because they have a definite interest in this kind of thing, knew what was going on. Some authors of other libs may not even be aware that they could so easily have their code whisked into stdlib, if it's solid enough. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
At 06:19 PM 12/12/2005 -0700, Mike Brown wrote: >Some authors of other libs may not even be aware that they could so >easily have their code whisked into stdlib, if it's solid enough. But here the definition of "solid enough" includes such credits as being written by the primary author of CPython's implementations of Unicode and regular expressions, and who can be reasonably be believed to be around to support and maintain the package for some time. I don't know who the "some authors" you mention are, but those are pretty tough credentials to match, as are the apparent popularity, Pythonicness, and performance of ElementTree. I find it rather hard to believe that there's another XML library that could have gotten through the approval process anywhere near as easily. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Martin> It's difficult to establish precise numbers, but I would expect Martin> that most readers of xml-sig are well aware of how DOM and SAX Martin> work, perhaps even better than ElementTree. Perhaps the corollary is that people who are not xml-sig readers will likely be put off by DOM and SAX. I couldn't tell you what they do, just that they were Too Hard (tm) for me to bother with XML in most situations. Then ElementTree came along. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Martin> It's difficult to establish precise numbers, but I would expect > Martin> that most readers of xml-sig are well aware of how DOM and SAX > Martin> work, perhaps even better than ElementTree. > > Perhaps the corollary is that people who are not xml-sig readers will likely > be put off by DOM and SAX. I couldn't tell you what they do, just that they > were Too Hard (tm) for me to bother with XML in most situations. Then > ElementTree came along. It seems pretty clear why DOM isn't Pythonic: it doesn't use Python's standard APIs for things that conceptually are "just" lists and dicts, or at least sequences and mappings. Also, the memory footprint is a bit outlandish. I don't think that SAX is unpythonic, but it's pretty low-level and mostly of use to people writing higher-level XML parsers (my parsexml module uses it). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Mike Brown wrote: > My fears are just that 1. XML-SIG is being seen as either irrelevant or as an > obstacle (perhaps due to the friction between Fredrik and Uche) and are thus > being sidestepped, and 2. other libs that could/should be contenders (Amara > and 4Suite are not in this list, by the way) are going to become further > marginalized by virtue of the fact that people will say "well, we have > ElementTree in stdlib already, why do we need (fill in the blank)?" And if they say so, they might be right! I firmly believe that the standard library should be a community-driven thing, not a committee-driven one. For that, two things need to happen for a library to become included: 1. the author of the library must explicitly offer it for inclusion. there is no point in "hijacking" the package into the library, even if the package license would allow to do so (factually, it typically doesn't, because it typically doesn't allow redistribution under a different license). So without the author's explicit endorsement, and promise to maintain it for some time (or some other set of people offering that), nothing will happen to (fill in the blank). 2. the users must indicate that they want to see the package as part of the library. Again, just that the author would like to contribute it isn't enough - there must be people supporting the inclusion of the package. Traditionally, we had a third step: 3. The BDFL must pronounce inclusion of the package. Now, while Guido has a firm vision for how the language proper should evolve, he often indicated that he can't really comment on some specific library because he doesn't know anything about the functionality it provides. So in the case of libraries, this requirement often is waived. > I suppose the same kind of implicit endorsements were given to minidom and > SAX, and that obviously hasn't prevented people from going out and using > ElementTree, lxml, etc., so I don't know... I can't predict the future. I'd > just feel better about it if everyone on XML-SIG, where people hang out > because they have a definite interest in this kind of thing, knew what was > going on. Some authors of other libs may not even be aware that they could so > easily have their code whisked into stdlib, if it's solid enough. That's part of the process. They could have read PEP 2, so they could have known to write a PEP and get it discussed. When they don't know that, they fail the basic test of "author support": if the author isn't really behind the integration of the package, the package really shouldn't be integrated (this is why I first predicted ElementTree would never become part of the library, because I assumed /F would not like the idea). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Phillip J. Eby wrote: > At 06:19 PM 12/12/2005 -0700, Mike Brown wrote: > >>Some authors of other libs may not even be aware that they could so >>easily have their code whisked into stdlib, if it's solid enough. > > > But here the definition of "solid enough" includes such credits as being > written by the primary author of CPython's implementations of Unicode and > regular expressions, and who can be reasonably be believed to be around to > support and maintain the package for some time. I don't know who the "some > authors" you mention are, but those are pretty tough credentials to match, > as are the apparent popularity, Pythonicness, and performance of ElementTree. > > I find it rather hard to believe that there's another XML library that > could have gotten through the approval process anywhere near as easily. > This can be observed simply by looking at who posts to python-dev. Certainly we see input from Fredrik on a fairly regular basis, whereas others appear infrequently or not at all. Absence from python-dev can't really be seen as expressing any keenness at all for one's code to be included in the core. If the authors of code aren't bothered about its promotion to the core I hardly think anyone else should be. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Guido van Rossum wrote: > On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >>Martin> It's difficult to establish precise numbers, but I would expect >>Martin> that most readers of xml-sig are well aware of how DOM and SAX >>Martin> work, perhaps even better than ElementTree. >> >>Perhaps the corollary is that people who are not xml-sig readers will likely >>be put off by DOM and SAX. I couldn't tell you what they do, just that they >>were Too Hard (tm) for me to bother with XML in most situations. Then >>ElementTree came along. > > It seems pretty clear why DOM isn't Pythonic: it doesn't use Python's > standard APIs for things that conceptually are "just" lists and dicts, > or at least sequences and mappings. Also, the memory footprint is a > bit outlandish. > > I don't think that SAX is unpythonic, but it's pretty low-level and > mostly of use to people writing higher-level XML parsers (my parsexml > module uses it). Having to define classes that conform to a certain API and registering instances of those classes as callbacks with the parser doesn't look that pythonic to me. An iterator API seems much more pythonic. Then again, pythonic is whatever you say that it is. ;) Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Martin v. Löwis wrote: > [...] > > It's difficult to establish precise numbers, but I would expect that > most readers of xml-sig are well aware of how DOM and SAX work, perhaps > even better than ElementTree. > > My main complaint about this was in the past that it is a Python-only > solution, so people working in multiple languages cannot reuse their > knowledge. It seems that this is irrelevant, as people don't work > in multiple languages so much. I still think that Python should continue > to provide standard APIs, for those that know how things are done > in Java. I think there could be a middle ground between one API for all XML processors in all languages (SAX+DOM) and every XML package having its own custom API. A common tree API for all Python XML processors might be beneficial. Maybe ElementTree can become that API? Or maybe a subset of the ElementTree API (I don't think the text and trail attributes should be in that API). Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Walter Dörwald wrote: > Having to define classes that conform to a certain API and registering > instances of those classes as callbacks with the parser doesn't look > that pythonic to me. An iterator API seems much more pythonic. If this is a comment on the ElementTree API, then /F must agree with you - iterparse [1] was added to the API earlier this year. . . Cheers, Nick. [1] http://effbot.org/zone/element-iterparse.htm -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Nick Coghlan wrote: > > Having to define classes that conform to a certain API and registering > > instances of those classes as callbacks with the parser doesn't look > > that pythonic to me. An iterator API seems much more pythonic. > > If this is a comment on the ElementTree API, then /F must agree with you - > iterparse was added to the API earlier this year. . . When xml.sax was added to Python, the standard approach was to create parsers that implemented the consumer pattern [1] and called methods either on the parser class itself, or on a target object. Examples include sgmllib, htmllib/formatter, and xmllib. After the discovery of efficient "pull parsing" patterns [2] and "using iterators to invert program logic" patterns (see e.g. the "anonymous blocks" thread from april this year [3], which generated a whole bunch of interesting PEPs), things have changed a bit. 1) http://effbot.org/zone/consumer.htm 2) http://mail.python.org/pipermail/xml-sig/2000-May/002335.html (Paul's xml.dom.pulldom module did make it into the standard library, but it don't seem to be used much, for some unknown reason...) 3) http://mail.python.org/pipermail/python-dev/2005-April/052753.html (lots of interesting posts here) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Nice that we now have ElementTree in the stdlib :-) Some questions: * Are you going to contribute cElementTree as well ? * What was the motivation to not include the whole ElementTree package ? * I'm missing the usual "Licensed to PSF under a Contributor Agreement." in the copyright notices of the files: http://www.python.org/psf/contrib.html I assume that you'll add these, right ? * How should users that want to use the latest and greatest (more recent) distribution directly from your site go about in their apps ? Using from...as contructs ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
M.-A. Lemburg wrote: > Some questions: > > * Are you going to contribute cElementTree as well ? yes, but there are some build issues we need to sort out first (both pyexpat and cET link to their own copies of expat) we also need to figure out how to import the bundled version; should it be cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree (which would then fallback on the Python version if cElementTree isn't built) ? > * What was the motivation to not include the whole ElementTree > package ? this is a perfect time to get rid of some little-used stuff. if there's enough user demand, we can always add a few more modules before 2.5 goes out of the door... > * I'm missing the usual "Licensed to PSF under a Contributor Agreement." > in the copyright notices of the files: > > http://www.python.org/psf/contrib.html > > I assume that you'll add these, right ? will fix. > * How should users that want to use the latest and greatest > (more recent) distribution directly from your site go about in > their apps ? Using from...as contructs ? from-import or import-as works fine ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Mike Brown writes: [ElementTree was accepted into stdlib immediately without discussion on XML-Sig. Seems like a lack of due process.] > Some authors of other libs may not even be aware that they could so > easily have their code whisked into stdlib, if it's solid enough. It's not the solidity of the CODE in ElementTree that secured the approval. It's not even the pythonicness of the API (although that's ElementTree's greatest strength). No, the reason for the rapid acceptance was the solidity of the *community support*. For a long time, lots of people (users, not just core developers) have been thinking to themselves "why isn't ElementTree the standard Python API for XML?". Once it was stated out loud (on c.l.py) and it was clear that /F supported the idea, there was little to discuss. Frankly, if at any time in the past several years the XML-SIG had published their consensus report on the "preferred API for XML" (or perhaps "preferred small set of APIs, each tuned for a specific purpose"), I expect it would have been incorporated in the core. This could have been done long before /F ever wrote ElementTree. But historically, this isn't what happened. I look at some other areas and find that Python tends to have one good (hopefully excellent) implementation of a given feature, and perhaps a few high-powered 3rd party implementations for special purposes. For instance, there's the datetime module which satisfies most users, then there are tools like mxDateTime for specialists. Most users of high-precision numbers make due with the built-in long type, but specialists use GMPY. Most users of threading find that the threading module is sufficient, but those who really want full co-routines get stackless. Expressed in this fashion, I have always felt that the XML-SIG was basically working on developing and standardizing the specialist tools for XML, with special attention paid to things like very high performance, very complete implementation of XML features, cross-language standardization, automatic object serialization, and other such features far removed from the basic "I want to read this file and it's in XML." Those are great areas, and there are people who need them (for some projects, I'm one of those people). However, ElementTree is one of the few libraries that have struck me as being canidates for the "one good implementation" that serves the basic needs of the typical user. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't think that SAX is unpythonic, but it's pretty low-level and > > mostly of use to people writing higher-level XML parsers (my parsexml > > module uses it). > > Having to define classes that conform to a certain API and registering > instances of those classes as callbacks with the parser doesn't look > that pythonic to me. An iterator API seems much more pythonic. Perhaps. Although the SAX API lets you leave a callback undefined if you don't have a need to handle those events; that's a bit trickier to do with an iterator. Also the different callbacks have different signatures. But since /F solved this for ElementTree I have to mostly agree with you. :-) > Then again, pythonic is whatever you say that it is. ;) Not at all. I will argue but I will also take arguments from others. Seriously. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Michael Chermside wrote: > Frankly, if at any time in the past several years the XML-SIG had > published their consensus report on the "preferred API for XML" > (or perhaps "preferred small set of APIs, each tuned for a specific > purpose"), I expect it would have been incorporated in the core. > This could have been done long before /F ever wrote ElementTree. > But historically, this isn't what happened. That's not true. The current xml package *is* the consensus of xml-sig. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On Tuesday 13 December 2005 15:02, Martin v. Löwis wrote: > That's not true. The current xml package *is* the consensus of > xml-sig. It pretty much was at the time, at any rate. It's not clear to me that the xml package shipped in 2.4 and several preceeding versions of Python would pass muster in the current XML-SIG. There's been a lot of evolution in the Python APIs for XML since then, and a lot of really interesting things have been tried with varying degrees of acceptance. Unless the XML-SIG wants to figure it out all over again, adding xml.etree to the standard library is probably the best near-term improvement that can be made. Speaking just for myself, I think this is fine, though I agree with Jim that an easier-to-use package management system would go a long way to avoid the issues related to whether something is in the standard library. Now, just what it means for a package management system to be easier to use might be harder to get us to agree on. :-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Fred wrote: > > That's not true. The current xml package *is* the consensus of > > xml-sig. > > It pretty much was at the time, at any rate. It's not clear to me that the > xml package shipped in 2.4 and several preceeding versions of Python would > pass muster in the current XML-SIG. There's been a lot of evolution in the > Python APIs for XML since then, and a lot of really interesting things have > been tried with varying degrees of acceptance. from what I can tell, most of the stuff under Lib/xml is between two and three years old. the last major PyXML sync appears to be against 1.82, in january 2003. there are a few bug fixes since then, but that's about it. what's the status of PyXML? is it time to move it over to svn.python.org and bring it up to 1.0 (whatever that would mean?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
I wrote: > Frankly, if at any time in the past several years the XML-SIG had > published their consensus report on the "preferred API for XML" > (or perhaps "preferred small set of APIs, each tuned for a specific > purpose"), I expect it would have been incorporated in the core. Martin v. Löwis objected: > That's not true. The current xml package *is* the consensus of > xml-sig. Fred Drake clarifies > It pretty much was at the time, at any rate. It's not clear to me that the > xml package shipped in 2.4 and several preceeding versions of Python would > pass muster in the current XML-SIG. Yes, I'm sorry about not being clearer, and thanks for correcting me. It was the more recent work in XML which I was thinking of. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't think that SAX is unpythonic, but it's pretty low-level and > > mostly of use to people writing higher-level XML parsers (my parsexml > > module uses it). > > Having to define classes that conform to a certain API and registering > instances of those classes as callbacks with the parser doesn't look > that pythonic to me. An iterator API seems much more pythonic. Strongly agree. This very morning I wrote a long tirade about how I wish Python had true coroutines, for the sole reason that I could wrap SAX in an iterator-based API. Eventually I decided it was SAX's fault for having such a crummy API, so I didn't post it. -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Guido van Rossum wrote: > On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> I don't think that SAX is unpythonic, but it's pretty low-level and >>> mostly of use to people writing higher-level XML parsers (my parsexml >>> module uses it). >> Having to define classes that conform to a certain API and registering >> instances of those classes as callbacks with the parser doesn't look >> that pythonic to me. An iterator API seems much more pythonic. > > Perhaps. Although the SAX API lets you leave a callback undefined if > you don't have a need to handle those events; that's a bit trickier to > do with an iterator. Changing the iterator to only generate the events you need requires passing information to the iterator. And when you do that you can just as well pass information about which function to call at which event. But IMHO the main difference isn't dispatching, but who's in control. > Also the different callbacks have different > signatures. True, I've always wondered why SAX uses a startelement callback which gets passed a complete attribute dictionary. IMHO for spam the following event sequence would be better: starttagbegin foo attributebegin bar text baz attributeend bar starttagend foo text spam endtag foo This would simplify signatures (always one string argument) and it would leave handling entity references inside attribute values to the application (or at least a higher level of the parser). > But since /F solved this for ElementTree I have to mostly agree with you. :-) Unfortunately there probably won't be that many parsers that support iterparse(). Most parsers existing outside the Python world use the callback model and turning a callback parser into a iterator parser requires support for incremental parsing (which has a certain latency) or stack switching tricks. >> Then again, pythonic is whatever you say that it is. ;) > > Not at all. I will argue but I will also take arguments from others. > Seriously. Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Fredrik Lundh wrote: > M.-A. Lemburg wrote: > >> Some questions: >> >> * Are you going to contribute cElementTree as well ? > > yes, but there are some build issues we need to sort out first (both pyexpat > and cET link to their own copies of expat) Great ! > we also need to figure out how to import the bundled version; should it be > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > (which would then fallback on the Python version if cElementTree isn't > built) ? If the semantics are identical I'd prefer the latter approach of using the faster variant if possible. >> * What was the motivation to not include the whole ElementTree >> package ? > > this is a perfect time to get rid of some little-used stuff. if there's > enough user > demand, we can always add a few more modules before 2.5 goes out of the > door... Ok. >> * I'm missing the usual "Licensed to PSF under a Contributor Agreement." >> in the copyright notices of the files: >> >> http://www.python.org/psf/contrib.html >> >> I assume that you'll add these, right ? > > will fix. > >> * How should users that want to use the latest and greatest >> (more recent) distribution directly from your site go about in >> their apps ? Using from...as contructs ? > > from-import or import-as works fine Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 14 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Guido van Rossum wrote: > On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > > Having to define classes that conform to a certain API and registering > > instances of those classes as callbacks with the parser doesn't look > > that pythonic to me. An iterator API seems much more pythonic. > > Perhaps. Although the SAX API lets you leave a callback undefined if > you don't have a need to handle those events; that's a bit trickier to > do with an iterator. Well, suppose you want to dump the text of a document. for e in iterparse(filename): if e.isText(): out.write(e.data) Not tricky. > > Also the different callbacks have different signatures. True. With SAX I always have to look up the signatures. The iterator yields Node-like objects in document order. I don't have to remember signatures. But the biggest advantage of an iterator-based API would be: when you hit an element, you can easily pass control to a function that knows how to parse that particular element. parsePlay() can call parseAct(), which can call parseScene(). To do anything like that with SAX, you have to write a bunch of dispatch code. -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > we also need to figure out how to import the bundled version; should it be > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > > (which would then fallback on the Python version if cElementTree isn't > > built) ? > > If the semantics are identical I'd prefer the latter approach > of using the faster variant if possible. That is my preference, too. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
M.-A. Lemburg wrote: >>we also need to figure out how to import the bundled version; should it be >>cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree >>(which would then fallback on the Python version if cElementTree isn't >>built) ? > > > If the semantics are identical I'd prefer the latter approach > of using the faster variant if possible. I have myself in the past used or overridden non-public methods of ElementTree, which I'm sure wouldn't work with cElementTree. While I'd also prefer automatic fallback, it would be nice if there was additionally an explicit path to each version. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On Wednesday 14 December 2005 12:39, Ian Bicking wrote: > I have myself in the past used or overridden non-public methods of > ElementTree, which I'm sure wouldn't work with cElementTree. While I'd > also prefer automatic fallback, it would be nice if there was > additionally an explicit path to each version. I think the whole PyXML v. the standard library dabacle has taught us that there should *always* be an explicit path to each version of a module or package. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Jeremy Hylton wrote: > On 12/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > > we also need to figure out how to import the bundled version; should it be > > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > > > (which would then fallback on the Python version if cElementTree isn't > > > built) ? > > > > If the semantics are identical I'd prefer the latter approach > > of using the faster variant if possible. > > That is my preference, too. it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the modules are 99% compatible, but there's always someone that relies on that last % (which is a result of ET being written in Python). at this point, I think it's more important to guarantee that changing "elementtree" to "xml.etree" will always work under Python 2.5 [1], than to have a new set of potential subtle incompatibility issues. but I have changed my mind before... 1) except for users that need a newer version, of course. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
/F writes: > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the > modules are 99% compatible, but there's always someone that relies > on that last % (which is a result of ET being written in Python). Yes! > at this point, I think it's more important to guarantee that changing > "elementtree" to "xml.etree" will always work under Python 2.5 [1], > than to have a new set of potential subtle incompatibility issues. but > I have changed my mind before... Consider changing it again. I fear that if ElementTree is part of the core without cElementTree, then a meme will spread which says (and PLEASE don't quote this!) "ElementTree has a great API, but it's just too slow for real work." We already know that Python is particularly susceptable to "too slow" memes, even invalid ones. I think the best all-around solution is to include cElementTree and use it wherever possible unless the user specially imports the pure-python version. Perhaps importing "xml.etree" gets you cElementTree unless that isn't compiled on your platform, but you can import "xml.pure_python.etree" or something like that to get the pure Python version if you really want it. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > /F writes: > > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the > > modules are 99% compatible, but there's always someone that relies > > on that last % (which is a result of ET being written in Python). > > Yes! > > > at this point, I think it's more important to guarantee that changing > > "elementtree" to "xml.etree" will always work under Python 2.5 [1], > > than to have a new set of potential subtle incompatibility issues. but > > I have changed my mind before... > > Consider changing it again. I fear that if ElementTree is part of the > core without cElementTree, then a meme will spread which says (and > PLEASE don't quote this!) "ElementTree has a great API, but it's > just too slow for real work." > > We already know that Python is particularly susceptable to "too slow" > memes, even invalid ones. I think the best all-around solution is to > include cElementTree and use it wherever possible unless the user > specially imports the pure-python version. Perhaps importing > "xml.etree" gets you cElementTree unless that isn't compiled on your > platform, but you can import "xml.pure_python.etree" or something > like that to get the pure Python version if you really want it. > I don't think this will necessarily happen. You are assuming people are going to know there is a faster way than ET written in Python. I think most people consider stuff in the stdlib good and fast enough for most uses and when they want faster they roll their own. And since I have always voted on the side of "have a C version only if someone wants to maintain a C version but don't have both C and Python", I say /F should include which ever he wants, but I personally vote for only one version. So if /F is going to continue to maintain cElementTree and since it is already written I say use that and just get the speed boost and eliminate the isssue of people relying on that 1% semantic difference between the Python and C version. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote: >On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > > We already know that Python is particularly susceptable to "too slow" > > memes, even invalid ones. I think the best all-around solution is to > > include cElementTree and use it wherever possible unless the user > > specially imports the pure-python version. Perhaps importing > > "xml.etree" gets you cElementTree unless that isn't compiled on your > > platform, but you can import "xml.pure_python.etree" or something > > like that to get the pure Python version if you really want it. > >I don't think this will necessarily happen. You are assuming people >are going to know there is a faster way than ET written in Python. Actually, he's said that the C version should be the default, with the Python version only used if you have subclassing needs that can't be met by the C version. >And since I have always voted on the side of "have a C version only if >someone wants to maintain a C version but don't have both C and >Python", I say /F should include which ever he wants, but I personally >vote for only one version. So if /F is going to continue to maintain >cElementTree and since it is already written I say use that and just >get the speed boost and eliminate the isssue of people relying on that >1% semantic difference between the Python and C version. Having a Python version available for Jython, PyPy, etc., is a good idea; Michael's proposal lets us have your cake (C version be the default) and eat it too (have the pure Python available for other platforms and for explicit use by subclassers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Michael Chermside wrote: > ... a meme will spread which says (and PLEASE don't quote this!) > "ElementTree has a great API, but it's just too slow for real work." +1 DNQOTW :-) (Do Not Quote Of The Week) --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
On 12/14/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote: > >On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > > > We already know that Python is particularly susceptable to "too slow" > > > memes, even invalid ones. I think the best all-around solution is to > > > include cElementTree and use it wherever possible unless the user > > > specially imports the pure-python version. Perhaps importing > > > "xml.etree" gets you cElementTree unless that isn't compiled on your > > > platform, but you can import "xml.pure_python.etree" or something > > > like that to get the pure Python version if you really want it. > > > >I don't think this will necessarily happen. You are assuming people > >are going to know there is a faster way than ET written in Python. > > Actually, he's said that the C version should be the default, with the > Python version only used if you have subclassing needs that can't be met by > the C version. > Ah, misread it. > > >And since I have always voted on the side of "have a C version only if > >someone wants to maintain a C version but don't have both C and > >Python", I say /F should include which ever he wants, but I personally > >vote for only one version. So if /F is going to continue to maintain > >cElementTree and since it is already written I say use that and just > >get the speed boost and eliminate the isssue of people relying on that > >1% semantic difference between the Python and C version. > > Having a Python version available for Jython, PyPy, etc., is a good idea; > Michael's proposal lets us have your cake (C version be the default) and > eat it too (have the pure Python available for other platforms and for > explicit use by subclassers. > Good point. My preference then would be to not directly expose it but have it there for the other distributions to use with an added note to make sure to not use anyt edge semantics that might crop up from the different versions since they might be using the Python version. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > A while ago there was some discussion about including > elementtree in the std lib. I can't remember what the > conclusion about that was, but if it does go ahead, > I'd like to suggest that it be reorganised a bit. > > I've just started playing with it, and having a > package called elementtree containing a module > called ElementTree containing a class called > ElementTree is just too confusing for words! Try the 2.5 alpha 1 just released, and you'll see that the toplevel package is now xml.etree. The module and class are still called ElementTree, though. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Apr 5, 2006, at 9:02 PM, Alex Martelli wrote: > > On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > >> A while ago there was some discussion about including >> elementtree in the std lib. I can't remember what the >> conclusion about that was, but if it does go ahead, >> I'd like to suggest that it be reorganised a bit. >> >> I've just started playing with it, and having a >> package called elementtree containing a module >> called ElementTree containing a class called >> ElementTree is just too confusing for words! > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > package is now xml.etree. The module and class are still called > ElementTree, though. It would be nice to have new code be PEP 8 compliant.. Specifically: Modules should have short, lowercase names, without underscores. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Bob Ippolito wrote: > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > > package is now xml.etree. The module and class are still called > > ElementTree, though. > > It would be nice to have new code be PEP 8 compliant.. it's not new code, and having *different* module names for the same well-established library isn't very nice to anyone. > Modules should have short, lowercase names, without underscores. the PEP changes over time. the ElementTree module was perfectly PEP-compatible when it was written. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Fredrik Lundh wrote: > it's not new code, and having *different* module names for the same > well-established library isn't very nice to anyone. > > > Modules should have short, lowercase names, without underscores. But if we don't start becoming stricter about the naming of things added to the stdlib, consistency of naming is never going to improve. Or should this wait for Py3k? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Thu, Apr 06, 2006, Greg Ewing wrote: > Fredrik Lundh wrote: >> >> it's not new code, and having *different* module names for the same >> well-established library isn't very nice to anyone. >> >>> Modules should have short, lowercase names, without underscores. > > But if we don't start becoming stricter about the naming of things > added to the stdlib, consistency of naming is never going to improve. > > Or should this wait for Py3k? For contributions that are also maintained separately from Python, I think compatibility with the external code has to have some importance. I vote we wait for Py3k. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Alex Martelli wrote: > On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > > >>A while ago there was some discussion about including >>elementtree in the std lib. I can't remember what the >>conclusion about that was, but if it does go ahead, >>I'd like to suggest that it be reorganised a bit. >> >>I've just started playing with it, and having a >>package called elementtree containing a module >>called ElementTree containing a class called >>ElementTree is just too confusing for words! > > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > package is now xml.etree. The module and class are still called > ElementTree, though. Note that lxml (which implements an ElementTree compatible API on top of libxml2) was using the 'etree' as a *module* (not a package name) before this move of ElementTree in the core. I had some discussions with Fredrik about making ElementTree in the Python core consistent with lxml, but no luck there. I.e., this in ElementTree: from elementtree.ElementTree import Element is this in lxml: from lxml.etree import Element and I believe in python 2.5 it's now: from xml.etree.ElementTree import Element which is not good in my opinion... (though also not a disaster) Regards, Martijn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Martijn Faassen wrote]
> I.e., this in ElementTree:
> ...
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/475126
import ElementTree from everywhere
try:
import xml.etree.ElementTree as ET # in python >=2.5
except ImportError:
try:
import cElementTree as ET # effbot's C module
except ImportError:
try:
import elementtree.ElementTree as ET # effbot's pure Python
module
except ImportError:
try:
import lxml.etree as ET # ElementTree API using libxml2
except ImportError:
import warnings
warning.warn("could not import ElementTree "
"(http://effbot.org/zone/element-index.htm)")
# Or you might just want to raise an ImportError here.
# Use ET.Element, ET.ElementTree, etc...
That is the current state.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Trent Mick wrote:
> That is the current state.
which reminds that maybe it's time to add an import helper to
the standard library, so you can do
stringio = import_search("cStringIO", "StringIO")
ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
db = import_search("superdb", "sqlite3", "fancydb", "dumbdb")
etc. without having to type in
for mod in ("cStringIO", "StringIO"):
try:
m = __import__(mod)
for p in mod.split(".")[1:]:
m = getattr(m, p, None)
if m is None:
raise ImportError
return m
except ImportError:
pass
else:
raise ImportError(mod)
all the time (or create those horridly nested try-except constructs).
or perhaps
try:
import cStringIO as stringio
retry ImportError:
import StringIO as stringio
except ImportError:
print "didn't work!"
would be a solution (sorry, wrong list).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Fredrik Lundh wrote]
> Trent Mick wrote:
>
> > That is the current state.
>
> which reminds that maybe it's time to add an import helper to
> the standard library, so you can do
>
> stringio = import_search("cStringIO", "StringIO")
> ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
> db = import_search("superdb", "sqlite3", "fancydb", "dumbdb")
To the 'imp' module? Hrm, would then maybe want to change the docs from:
3.21 imp -- Access the import internals
to
3.21 imp -- Access the import internals and some other useful importing
stuff
:)
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Trent Mick wrote: > try: > import xml.etree.ElementTree as ET # in python >=2.5 > except ImportError: >... etc ad nauseam For situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.ElementTree or lxml.etree as ET -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Greg Ewing <[EMAIL PROTECTED]> wrote: >> try: >> import xml.etree.ElementTree as ET # in python >=2.5 >> except ImportError: > >... etc ad nauseam > > For situations like this I've thought it might > be handy to be able to say > >import xml.etree.ElementTree or cElementTree or \ > elementtree.ElementTree or lxml.etree as ET Astonishingly cute. +1. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On 4/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Trent Mick wrote:> try:> import xml.etree.ElementTree as ET # in python >=2.5> except ImportError: >... etc ad nauseamFor situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.ElementTree or lxml.etree as ETThat does look cute (note that you can use parentheses rather than newline-escaping to continue the line.) I assume it should come with: from (xml.etree.cElementTree or xml.etree.ElementTree or elementtree.cElementTree or elementtree.ElementTree or lxml.etree) import ElementTree as ET(Parentheses there are currently illegal.) But should it also come with:from xml.etree import (cElementTree or ElementTree) as ElementTreeand combined:from xml.etree or elementtree import cElementTree or ElementTree as ElementTree and of course combined with explicit-relative imports:from .custometree or xml.etree or elementtree import cElementTree or ElementTree as ETor is that all going too far? :)-- Thomas Wouters < [EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Greg Ewing wrote: > Trent Mick wrote: > >> try: >> import xml.etree.ElementTree as ET # in python >=2.5 >> except ImportError: > >... etc ad nauseam > > For situations like this I've thought it might > be handy to be able to say > >import xml.etree.ElementTree or cElementTree or \ > elementtree.ElementTree or lxml.etree as ET Suppose I wanted to implement that, what would be the best strategy to follow: - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c - emit different bytecodes in compile.c - directly create TryExcept AST nodes in ast.c ? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Georg Brandl wrote: > Greg Ewing wrote: >> Trent Mick wrote: >> >>> try: >>> import xml.etree.ElementTree as ET # in python >=2.5 >>> except ImportError: >> >... etc ad nauseam >> >> For situations like this I've thought it might >> be handy to be able to say >> >>import xml.etree.ElementTree or cElementTree or \ >> elementtree.ElementTree or lxml.etree as ET > > Suppose I wanted to implement that, what would be the best strategy > to follow: > - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c > - emit different bytecodes in compile.c > - directly create TryExcept AST nodes in ast.c Definitely option 3, since you only have to modify the parser and the AST compiler. To change it in compile.c, you have to first modify the parser, the AST definition and the AST compiler in order to get the info to the bytecode compiler. To change it in ceval.c, you have to first modify the parser, the AST definition, the AST compiler and the bytecode compiler in order to get the info to the eval loop. Given that import statements aren't supposed to be in time critical code, go for the easy option :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On 4/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Bob Ippolito wrote: > > > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > > > package is now xml.etree. The module and class are still called > > > ElementTree, though. > > > > It would be nice to have new code be PEP 8 compliant.. > > it's not new code, and having *different* module names for the same > well-established library isn't very nice to anyone. (It's not new code, but it is new code to the stdlib.) How about doing a rename but creating some kind of alias for the current names? That would serve everyone. (I also find the current naming to be unfortunate and stumble over it every time.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Thomas Wouters suggested "import ... or" syntax] > or is that all going too far? :) Yes. It is overkill. The number of different ways to import ElementTree is perhaps unfortunate but it is a mostly isolated incident: effbot providing pure and c versions, it being popular and hence having other implementations *and* quickly getting into the core. The original issue was that the various import paths to ElementTree are a little confusing. Adding "or" syntax doesn't change that. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Nick Coghlan wrote: > Georg Brandl wrote: >> Greg Ewing wrote: >>> Trent Mick wrote: >>> try: import xml.etree.ElementTree as ET # in python >=2.5 except ImportError: >>> >... etc ad nauseam >>> >>> For situations like this I've thought it might >>> be handy to be able to say >>> >>>import xml.etree.ElementTree or cElementTree or \ >>> elementtree.ElementTree or lxml.etree as ET >> >> Suppose I wanted to implement that, what would be the best strategy >> to follow: >> - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c >> - emit different bytecodes in compile.c >> - directly create TryExcept AST nodes in ast.c > > Definitely option 3, since you only have to modify the parser and the AST > compiler. > > To change it in compile.c, you have to first modify the parser, the AST > definition and the AST compiler in order to get the info to the bytecode > compiler. > > To change it in ceval.c, you have to first modify the parser, the AST > definition, the AST compiler and the bytecode compiler in order to get the > info to the eval loop. > > Given that import statements aren't supposed to be in time critical code, go > for the easy option :) Well, if there's an encouraging word from more developers, I can try it. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Georg Brandl wrote: > Suppose I wanted to implement that, what would be the best strategy > to follow: > - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c > - emit different bytecodes in compile.c > - directly create TryExcept AST nodes in ast.c I'd probably go for the third option. Isn't that the sort of thing the fancy new ast system is designed for? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
