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
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
[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
im
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
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
>>
>>impor
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 cEl
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
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 cElem
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.Eleme
[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
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_se
[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
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
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 becomi
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
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 nam
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
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 wit
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 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-ar
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]
___
Pyt
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 whereve
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!
>
/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 changin
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 cElement
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
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 pref
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
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.
>
>
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 i
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 cla
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 cert
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 ob
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 be
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 must
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.
> T
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 cert
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 solid
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
cElem
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
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 a
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 w
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,
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
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
> wr
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
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
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
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
"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. Bo
> 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 direc
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 py
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
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
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
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+AP
57 matches
Mail list logo
