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
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
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). /F ___ 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
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. /F ___ 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 foo bar=baz/spam/foo 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. fdrake at acm.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
/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
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
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
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 /F ___ 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
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
