Eli Bendersky eli...@gmail.com added the comment:
Note: last traces of Python bootstrap code were removed from _elementtree in
changeset 652d148bdc1d
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Markus com...@gmx.ch added the comment:
New bug - C implementation of ElementTree: Inheriting from Element breaks text
member
http://bugs.python.org/issue14849
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Markus com...@gmx.ch added the comment:
Hi,
the C implementation of ElementTree do not support namespaces for find/all/... .
To me this is a serious regression, as I rely on ElementTree namespace support,
and 3.3 would break it with this change.
Breaking namespace support is a fundamental
Changes by Markus com...@gmx.ch:
Removed file:
http://bugs.python.org/file25598/findall_takes_no_keywords_anymore.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Markus com...@gmx.ch added the comment:
The file was bad, sorry.
re-attached
--
Added file:
http://bugs.python.org/file25599/findall_takes_no_keywords_anymore.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
Markus (cmn): Please file a separate issue, which will be a release blocker for
3.3 release. (It's not the only regression.)
--
___
Python tracker rep...@bugs.python.org
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
Temporary very ugly workaround (before importing xml.etree.ElementTree) is:
import sys
sys.modules[_elementtree] = None
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti ezio.melo...@gmail.com added the comment:
It seems to me that namespaces are actually supported, but they are accepted
only as positional args and not keyword args, so this should be easy to fix.
--
___
Python tracker
Markus com...@gmx.ch added the comment:
As advised I opened a new bug on this:
http://bugs.python.org/issue14818
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Éric Araujo mer...@netwok.org added the comment:
I don’t see benefits in removing cET.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Ezio Melotti ezio.melo...@gmail.com added the comment:
I'm still not sure that's the best option. Without deprecation people will
keep using cElementTree and we will have to keep it around forever (or at least
until Python4 and then have a 3to4 to fix the import).
This might be fine, but as a
Eli Bendersky eli...@gmail.com added the comment:
Emitting a deprecation warning on importing cElementTree has been rejected in
the pydev list. The other remaining tasks have new issues on them, so this
issue is done now.
--
___
Python tracker
Ezio Melotti ezio.melo...@gmail.com added the comment:
FWIW the JSON doc doesn't even mention the acceleration module _json, but since
people here are used to import cElementTree I think it should be mentioned that
it's now deprecated and accelerations are used automatically, so something like
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 65fc79fb4eb2 by Florent Xicluna in branch 'default':
Issue #13988: cElementTree is deprecated and the _elementtree accelerator is
automatically used whenever available.
http://hg.python.org/cpython/rev/65fc79fb4eb2
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset e9cf34d56ff1 by Florent Xicluna in branch 'default':
Fix xml_etree_c test error (follow up of issue #13988).
http://hg.python.org/cpython/rev/e9cf34d56ff1
--
___
Python
Florent Xicluna florent.xicl...@gmail.com added the comment:
Now the merge is done. Thank you Eli for the effort, and to the other
contributors for the review.
Following topics may need further work:
- add a Deprecation warning for cElementTree? it will annoy the package
maintainers which
Eli Bendersky eli...@gmail.com added the comment:
I would add to the TODO - improve the documentation of the module. Opened issue
14006 for this.
--
resolution: fixed -
stage: committed/rejected - needs patch
status: closed - open
___
Python
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Eli Bendersky eli...@gmail.com added the comment:
I started going over the deprecated methods in ElementTree and ran into a more
serious problem. XmlParser.doctype() is listed as deprecated, and indeed
ElementTree (the Python version) issues a deprecation warning. However, the C
Philip Jenvey pjen...@underboss.org added the comment:
DeprecationWarnings aren't that annoying anymore now that they're silent by
default. It should at least have a PendingDeprecationWarning
--
nosy: +pjenvey
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
The doctype() problem is deeper, since neither does TreeBuilder implement it
(although for this class it's not even deprecated). Since this appears to be a
problem in 3.2 as well, I'm opening a new issue - 14007, to track this.
--
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153325
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153327
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Eli Bendersky eli...@gmail.com added the comment:
Opened issue 14007 to track the doctype() problem
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Eli Bendersky eli...@gmail.com added the comment:
Opened issue 14007 to track the doctype() problem
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Florent Xicluna florent.xicl...@gmail.com added the comment:
There was a discussion in December which ruled out some CPython too specific
implementation details from the documentation.
http://mail.python.org/pipermail/python-dev/2011-December/115063.html
Maybe it's better to remove these 2
Florent Xicluna florent.xicl...@gmail.com added the comment:
Updated patch:
- add 'XMLID' and 'register_namespace' to the ElementTree.__all__
- the comment says explicitly that cElementTree is deprecated
- exercise the deprecated module with the tests
--
Added file:
Eli Bendersky eli...@gmail.com added the comment:
Florent,
Your updated patch looks good. I think that the explicit import of
_namespace_map into cElementTree is just to satisfy some weird magic in the
tests and can probably be removed as well (along with the weird magic :-), but
that's not
Eli Bendersky eli...@gmail.com added the comment:
By the way, I see that if the explicit import of _namespace_map is commented
out, the test_xml_etree_c test fails because it's not in the __all__ list. So
the test can just import it directly with:
from xml.etree.ElementTree import
Florent Xicluna florent.xicl...@gmail.com added the comment:
from xml.etree.ElementTree import _namespace_map
And the import in cElementTree won't be necessary.
After all, _namespace_map is definitely not a public API!
Because of the interaction of the support.import_fresh_module with the
Eli Bendersky eli...@gmail.com added the comment:
Alright, it's not really important at this point and can be cleaned up
later.
I will probably commit code and documentation at once. It makes things
easier regarding traceability.
Sounds good
--
Eli Bendersky eli...@gmail.com added the comment:
The more I think about it, the more the bootstrap code in _elementtree.c annoys
me. It's the only instance of calling PyRun_String in Modules/ !
It's hackish and causes ugly import problems. If the C code needs stdlib
functionality like
Stefan Behnel sco...@users.sourceforge.net added the comment:
Eli Bendersky, 11.02.2012 09:08:
The more I think about it, the more the bootstrap code in _elementtree.c
annoys me. It's the only instance of calling PyRun_String in Modules/ !
It's hackish and causes ugly import problems. If
Eli Bendersky eli...@gmail.com added the comment:
I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular,
Florent Xicluna florent.xicl...@gmail.com added the comment:
Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail,
because it can't find fromstring and fromstringlist.
Ooops, I cut some redundancy after running the tests, and I forgot to re-add
the import. You're right.
Florent Xicluna florent.xicl...@gmail.com added the comment:
Updated patch:
- fixed missing import and missing alias
- moved the XMLTreeBuilder alias to the Python module
--
___
Python tracker rep...@bugs.python.org
Changes by Florent Xicluna florent.xicl...@gmail.com:
Added file: http://bugs.python.org/file24485/issue13988_prepare_pep399_v2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 31dfb4be934d by Florent Xicluna in branch 'default':
Issue #13988: move the python bootstrap code to cElementTree.py, and remove
obsolete code for Python 2.4 and 2.5.
http://hg.python.org/cpython/rev/31dfb4be934d
Florent Xicluna florent.xicl...@gmail.com added the comment:
I've pushed this first part, which is just a code refactoring.
I tried to work out a patch for the second part.
The tricky thing is because of xml.etree still using doctests.
The patch for the tests seems to be enough small and
Eli Bendersky eli...@gmail.com added the comment:
Another random cleanup idea:
ElementTree.py has this code:
try:
from . import ElementPath
except ImportError:
ElementPath = _SimpleElementPath()
Since in the stdlib ElementPath.py is always there, this is meaningless, so I'd
say this
Changes by Tshepang Lekhonkhobe tshep...@gmail.com:
--
nosy: +tshepang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
___
Éric Araujo mer...@netwok.org added the comment:
I think that 3.2 and 2.7 should get a doc note about cET
What doc note?
I was referring to one of the points raised in the email thread: the docs don’t
tell people that they can import a faster ET version, cET.
--
Eli Bendersky eli...@gmail.com added the comment:
I was referring to one of the points raised in the email thread: the docs
don’t tell people that they can import a faster ET version, cET.
Well, they *do*, but very modestly :-) I agree that should be improved and
emphasized a bit, perhaps
Eli Bendersky eli...@gmail.com added the comment:
Florent,
The issue13988_fold_cET_behind_ET.diff patch looks good to me. Unless there are
objections from others, you can commit! Even the tests became simpler now,
that's awesome ;-)
Now, what's left for this issue:
1. Update the
Eli Bendersky eli...@gmail.com added the comment:
Attaching a patch for Doc/library/xml.etree.elementtree.rst and Misc/NEWS.
The doc notice is modeled after a similar notice in the doc of 'pickle'. Note
that I've also removed the mention that effbot's site is the home of the
development
Eli Bendersky eli...@gmail.com added the comment:
Florent,
Just something minor I noticed in the new cElementTree.py:
# Wrapper module for _elementtree
from xml.etree.ElementTree import *
# Not in __all__
from xml.etree.ElementTree import ElementPath, XMLID, register_namespace
The
Éric Araujo mer...@netwok.org added the comment:
perhaps even mentioning (at least in the 3.2 doc) that in 3.3 it's going
to be done by default. Is that accepted practice?
I don’t think we ever do that, and it would be confusing.
-1 to mentioning _elementtree, an implementation detail. What
Eli Bendersky eli...@gmail.com added the comment:
Éric,
Could you please open a new issue (with a dependency on this one) and explain
there clearly what you want/mean?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
New submission from Eli Bendersky eli...@gmail.com:
Following the discussion on python-dev [1], this issue will track the
re-organization of Lib/xml/etree to expose the C implementation (_elementtree)
by default when importing ElementTree. The test suite will also have to be
updated - it's
Eli Bendersky eli...@gmail.com added the comment:
Oh, and not to forget: the documentation has to be updated to just not mention
cElementTree any longer. For the user, the fact that a fast C library is
invoked underneath should be invisible.
--
___
Stefan Behnel sco...@users.sourceforge.net added the comment:
Eli Bendersky, 10.02.2012 15:52:
* The current contents of xml/etree/ElementTree.py will move to
xml/etree/pyElementTree.py
IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a
Eli Bendersky eli...@gmail.com added the comment:
Hmm, that may be PEP 399:
If an acceleration module is provided it is to be named the same as the
module it is accelerating with an underscore attached as a prefix, e.g.,
_warnings for warnings. The common pattern to access the accelerated
Eli Bendersky eli...@gmail.com added the comment:
IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a lengthy discussion on python-dev (or the py3k
list?) back in the old pre-3.0 days, maybe there's even a PEP?
If there's a convention, I'll
Stefan Behnel sco...@users.sourceforge.net added the comment:
Eli Bendersky, 10.02.2012 16:43:
I don't see a compelling enough reason to break imports in existing code by
removing the cElementTree module, so we should not do that.
Agreed. Perhaps it should just be deprecated?
Given that
Ezio Melotti ezio.melo...@gmail.com added the comment:
A note in the doc is easy to miss IMHO, and since DeprecationWarnings are
silenced by default, I don't think they will affect the final users.
A different problem is that developers will have to check for the Python
version if they want
Eli Bendersky eli...@gmail.com added the comment:
If possible I would avoid pyElementTree,
I suppose it's possible, but I'm genuinely interested in a technical reason for
doing so. The approach suggested in PEP 399 is useful for module in which part
of the functionality is implemented in C,
Florent Xicluna florent.xicl...@gmail.com added the comment:
If possible I would avoid pyElementTree,
Me too:
- __name__ and __qualname__ would be less confusing
- the cElementTree accelerator uses large parts of Python implementation
ElementTree is different - it's pretty much two
Eli Bendersky eli...@gmail.com added the comment:
From a performance point of view, consider the (by far) common case
- where _elementtree *is* successfully imported.
... for each invocation, the whole import of the Python code has
to be done, just to reach the overriding import * at the
Eli Bendersky eli...@gmail.com added the comment:
Oops, in last message:
s/there will be circular dependencies/there will not be circular dependencies/
--
stage: needs patch -
type: performance -
___
Python tracker rep...@bugs.python.org
Ezio Melotti ezio.melo...@gmail.com added the comment:
In xml/etree there is:
- ElementTree: tries to import cElementTree. On success, done. On
ImportError, imports pyElementTree
- pyElementTree: the pure Python implementation
- cElementTree: sets up the bootstrap Python code and tries to
Eli Bendersky eli...@gmail.com added the comment:
What I had in mind is more like:
- ElementTree: defines the python code and if _elementtree is available
overrides part of it with the functions imported from it;
The problem with this is the bootstrap Python code executed by
_elementtree.
Ezio Melotti ezio.melo...@gmail.com added the comment:
- ElementTree: defines the python code and if _elementtree is
available overrides part of it with the functions imported from it;
The problem with this is the bootstrap Python code executed by
_elementtree.
This might become
Florent Xicluna florent.xicl...@gmail.com added the comment:
The first step is to strip out the cElementTree bootstrap code from the C
module.
I did it in the attached patch (plus removal of obsolete code for copy() in
Python 2.4).
This passes the unmodified tests test_xml_etree and
Eli Bendersky eli...@gmail.com added the comment:
Ezio,
We are assuming that _elementtree might be missing, but what are the cases
where this might actually happen? Other implementations like PyPy? Exotic
platforms that can't compile _elementtree?
I guess both. To make the stdlib work on
Eli Bendersky eli...@gmail.com added the comment:
Florent, thanks for the patch - at this point code is more useful than talk :-)
Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail, because
it can't find fromstring and fromstringlist. This gets fixed when I import
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
___
Éric Araujo mer...@netwok.org added the comment:
I strongly feel that existing code importing ElementTree or cElementTree should
not be broken. Let’s add transparent import from _elementtree to ElementTree
without breaking existing uses of cET.
I think that 3.2 and 2.7 should get a doc note
Eli Bendersky eli...@gmail.com added the comment:
I strongly feel that existing code importing ElementTree or cElementTree
should not be broken. Let’s add transparent import from _elementtree to
ElementTree without breaking existing uses of cET.
AFAICS there's currently no disagreement
68 matches
Mail list logo
