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
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 \
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 \
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 \
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
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..
[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
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
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
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
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
[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
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 =
[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,
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 \
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
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,
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
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
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
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
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.
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
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
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
/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
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
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]
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
