Stefan Behnel wrote:
>> also, putting large documents in a *single* Python string can be quite
>> inefficient. it's often more efficient to use lists of string fragments.
>
> That's a pretty general statement. Do you mean in terms of reading from that
> string (which at least in lxml is a straig
Fredrik Lundh wrote:
> Stefan Behnel wrote:
>
>>> My take on the API decision in question was always that a file is
>>> inherently an XML *document*, while a string is inherently an XML
>>> *fragment*.
>>
>> Not inherently, no. I know some people who do web processing with an XML
>> document comin
Stefan Behnel wrote:
>> My take on the API decision in question was always that a file is
>> inherently an XML *document*, while a string is inherently an XML
>> *fragment*.
>
> Not inherently, no. I know some people who do web processing with an XML
> document coming in as a string (from an HTTP
Hi,
Chris Mellon wrote:
> On that note, I really don't like APIs that take either a file name or
> a file object - I can open my own files, thanks.
... and HTTP URLs, and FTP URLs. In lxml, there is a performance difference
between passing an open file (which is read in Python space using the rea
On Jan 2, 2008 8:56 AM, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
>
> > Fredrik, if you're reading this, I'm curious what your reason is. I don't
> > have an opinion on whether you should or shouldn't treat files and
> > strings the same way. Over to you...
>
> as Diez shows
Steven D'Aprano wrote:
> Fredrik, if you're reading this, I'm curious what your reason is. I don't
> have an opinion on whether you should or shouldn't treat files and
> strings the same way. Over to you...
as Diez shows, it's all about use cases.
and as anyone who's used my libraries or read
To answer something posted deep down... It is fine with me if there are two
functions - one to parse a file or file handler and one to parse a string,
yet the returned objects should be consistent.
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 01 Jan 2008 12:59:44 -0700, Steven Bethard wrote:
> Steven D'Aprano wrote:
>> On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
>>
>>> And codemonkeys know that in python
>>>
>>> doc = et.parse(StringIO(string))
>>>
>>> is just one import away
>>
>> Yes, but to play devil's adv
Steven D'Aprano wrote:
> On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
>
>> And codemonkeys know that in python
>>
>> doc = et.parse(StringIO(string))
>>
>> is just one import away
>
> Yes, but to play devil's advocate for a moment,
>
> doc = et.parse(string_or_file)
>
> would be
On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
> And codemonkeys know that in python
>
> doc = et.parse(StringIO(string))
>
> is just one import away
Yes, but to play devil's advocate for a moment,
doc = et.parse(string_or_file)
would be even simpler.
Is there any reason why it
Steven D'Aprano schrieb:
> On Tue, 01 Jan 2008 01:53:47 +, Peter Pei wrote:
>
>> You are talking shit. It is never about whether it is hard to write a
>> wrapper. It is about bad design. I should be able to parse a string and
>> a file in exactly same way, and that should be provided as part o
Peter Pei wrote:
> To be preise
[...]
Preise the lord, not me. :)
Happy New Year!
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 01 Jan 2008 01:53:47 +, Peter Pei wrote:
> You are talking shit. It is never about whether it is hard to write a
> wrapper. It is about bad design. I should be able to parse a string and
> a file in exactly same way, and that should be provided as part of the
> package.
Oh my, somebod
To be preise, XPath is not fully supported. Don't be a smart asshole.
=
"Stefan Behnel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Peter Pei wrote:
>> One bad design about elementtree is that it has different wa
You are talking shit. It is never about whether it is hard to write a
wrapper. It is about bad design. I should be able to parse a string and a
file in exactly same way, and that should be provided as part of the
package.
Looks like you are just a code monkey not a designer, so I forgive you. Y
Peter Pei wrote:
> One bad design about elementtree is that it has different ways parsing a
> string and a file, even worse they return different objects:
> 1) When you parse a file, you can simply call parse, which returns a
> elementtree, on which you can then apply xpath;
ElementTree doesn't su
16 matches
Mail list logo
