On Mon, 26 Aug 2013 23:45:55 -0400
Scott Dial wrote:
> On 8/26/2013 8:51 AM, Antoine Pitrou wrote:
> > Le Mon, 26 Aug 2013 08:24:58 -0400,
> > Tres Seaver a écrit :
> >> On 08/26/2013 04:36 AM, Antoine Pitrou wrote:
> >>> event-driven processing using network libraries
> >>
> >> Maybe I missed so
Simon Cross, 27.08.2013 09:58:
> On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote:
>> What do you mean, "all events have to be ready"?
>> If you look at the unit tests, the events are generated on-the-fly,
>> not at the end of the document.
>> (exactly the same as iterparse(), except that iter
Le Tue, 27 Aug 2013 09:58:57 +0200,
Simon Cross a écrit :
> On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou
> wrote:
> > What do you mean, "all events have to be ready"?
> > If you look at the unit tests, the events are generated on-the-fly,
> > not at the end of the document.
> > (exactly the sa
On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote:
> What do you mean, "all events have to be ready"?
> If you look at the unit tests, the events are generated on-the-fly,
> not at the end of the document.
> (exactly the same as iterparse(), except that iterparse() is blocking)
So you have to
On 8/26/2013 8:51 AM, Antoine Pitrou wrote:
> Le Mon, 26 Aug 2013 08:24:58 -0400,
> Tres Seaver a écrit :
>> On 08/26/2013 04:36 AM, Antoine Pitrou wrote:
>>> event-driven processing using network libraries
>>
>> Maybe I missed something: why should considerations from that topic
>> influence the
Ryan wrote:
Nonblocking sounds too Internet-related. How about...flow?
AsyncParser?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
Nonblocking sounds too Internet-related. How about...flow?
Ah, I'll probably still end up using Expat regardless.
Eli Bendersky wrote:
>On Mon, Aug 26, 2013 at 10:40 AM, Paul Moore
>wrote:
>
>> On 26 August 2013 17:40, Eli Bendersky wrote:
>>
>>> Yes, exactly :-) "Incremental", though, seems
Paul Moore, 26.08.2013 19:40:
> On 26 August 2013 17:40, Eli Bendersky wrote:
>
>> Yes, exactly :-) "Incremental", though, seems to support the conjecture
>> that it's the input. Which is true, but, since XMLParser is also
>> "incremental" in this sense, slightly confusing.
>
> As a data point, u
On Mon, Aug 26, 2013 at 10:40 AM, Paul Moore wrote:
> On 26 August 2013 17:40, Eli Bendersky wrote:
>
>> Yes, exactly :-) "Incremental", though, seems to support the conjecture
>> that it's the input. Which is true, but, since XMLParser is also
>> "incremental" in this sense, slightly confusing.
How about StreamParser? I mean, even if it isn't quite the same, that name
would still make sense.
Eli Bendersky wrote:
>On Mon, Aug 26, 2013 at 8:57 AM, Antoine Pitrou
>wrote:
>
>> Le Mon, 26 Aug 2013 17:44:41 +0200,
>> Simon Cross a écrit :
>> > On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitr
On 26 August 2013 17:40, Eli Bendersky wrote:
> Yes, exactly :-) "Incremental", though, seems to support the conjecture
> that it's the input. Which is true, but, since XMLParser is also
> "incremental" in this sense, slightly confusing.
As a data point, until you explained the difference betwe
On Mon, Aug 26, 2013 at 9:21 AM, Antoine Pitrou wrote:
> Le Mon, 26 Aug 2013 09:14:38 -0700,
> Eli Bendersky a écrit :
> >
> > Antoine, you opted out of the tracker issue but I feel it's fair to
> > let you know that after a lot of discussion with Nick and Stefan (*),
> > we've settled on renami
Le Mon, 26 Aug 2013 09:14:38 -0700,
Eli Bendersky a écrit :
>
> Antoine, you opted out of the tracker issue but I feel it's fair to
> let you know that after a lot of discussion with Nick and Stefan (*),
> we've settled on renaming the input methods to feed & close, and the
> output method to rea
On Mon, Aug 26, 2013 at 8:57 AM, Antoine Pitrou wrote:
> Le Mon, 26 Aug 2013 17:44:41 +0200,
> Simon Cross a écrit :
> > On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou
> > wrote:
> > > Because this API is mostly useful when the data is received (*) at a
> > > slow enough speed - which usually
Le Mon, 26 Aug 2013 17:44:41 +0200,
Simon Cross a écrit :
> On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou
> wrote:
> > Because this API is mostly useful when the data is received (*) at a
> > slow enough speed - which usually means from the network, not from a
> > hard drive.
>
> It looks like
On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou wrote:
> Because this API is mostly useful when the data is received (*) at a
> slow enough speed - which usually means from the network, not from a
> hard drive.
It looks like all the events have to be ready before one can start
iterating over .eve
Le Mon, 26 Aug 2013 08:24:58 -0400,
Tres Seaver a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/26/2013 04:36 AM, Antoine Pitrou wrote:
> > event-driven processing using network librarie
>
> Maybe I missed something: why should considerations from that topic
> influence th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2013 04:36 AM, Antoine Pitrou wrote:
> event-driven processing using network librarie
Maybe I missed something: why should considerations from that topic
influence the design of an API for XML processing? 'feed' and 'close'
make much more s
Le Sat, 24 Aug 2013 14:42:24 -0400,
Terry Reedy a écrit :
> >
> > And these for IncrementalParser:
> >
> > data_received(data)
> > Feed the given bytes data to the incremental parser.
>
> Longer, awkward, and to me ugly in comparison to 'feed'. Since it
> seems to mean more or less
Eli Bendersky writes:
> On Sat, Aug 24, 2013 at 5:55 PM, Stephen J. Turnbull
> wrote:
>> FWIW, as somebody who can recall using ET exactly once,
>> IncrementalParser is what I used.
> Just to be on the safe side, I want to make sure that you indeed
> mean IncrementalParser, which was comm
On Sat, Aug 24, 2013 at 5:55 PM, Stephen J. Turnbull wrote:
> Eli Bendersky writes:
>
> > I'm strongly opposed to reverting [the change to ElementTree]
> > because it cleaned up messy code duplication and actually make the
> > code size smaller. While I agree that the API of incremental parsing
Eli Bendersky writes:
> I'm strongly opposed to reverting [the change to ElementTree]
> because it cleaned up messy code duplication and actually make the
> code size smaller. While I agree that the API of incremental parsing
> should be given another look, IncrementalParser can also be seen a
On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan wrote:
> On 25 August 2013 00:26, Nick Coghlan wrote:
> > On 25 August 2013 00:13, Antoine Pitrou wrote:
> >> On Sun, 25 Aug 2013 00:03:01 +1000
> >> Nick Coghlan wrote:
> >>> If Stefan's "please revert this" as lxml.etree maintainer isn't
> >>> en
On 8/24/2013 10:03 AM, Nick Coghlan wrote:
I have not used ET or equivalent, but I do have opinions on function names.
Looking at the current documentation of ElementTree sets of alarm
bells on that front, as it contains the following method descriptions
for XMLParser:
close()
Fi
On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan wrote:
> On 25 August 2013 00:26, Nick Coghlan wrote:
> > On 25 August 2013 00:13, Antoine Pitrou wrote:
> >> On Sun, 25 Aug 2013 00:03:01 +1000
> >> Nick Coghlan wrote:
> >>> If Stefan's "please revert this" as lxml.etree maintainer isn't
> >>> en
On 25 August 2013 00:26, Nick Coghlan wrote:
> On 25 August 2013 00:13, Antoine Pitrou wrote:
>> On Sun, 25 Aug 2013 00:03:01 +1000
>> Nick Coghlan wrote:
>>> If Stefan's "please revert this" as lxml.etree maintainer isn't
>>> enough, then I'm happy to add a "please revert this" as a core
>>> co
On 25 August 2013 00:13, Antoine Pitrou wrote:
> On Sun, 25 Aug 2013 00:03:01 +1000
> Nick Coghlan wrote:
>> If Stefan's "please revert this" as lxml.etree maintainer isn't
>> enough, then I'm happy to add a "please revert this" as a core
>> committer that is confused about how and when the new t
On Sun, 25 Aug 2013 00:03:01 +1000
Nick Coghlan wrote:
> If Stefan's "please revert this" as lxml.etree maintainer isn't
> enough, then I'm happy to add a "please revert this" as a core
> committer that is confused about how and when the new tulip-inspired
> incremental parsing API should be used
On 24 August 2013 20:58, Antoine Pitrou wrote:
> Someone can take the whole thing over if they want to, change the API
> and make it more shiny or different, tweak the implementation to suit
> it better to their own aesthetic sensibilities, but please don't revert
> an useful feature unless it's b
On Sat, 24 Aug 2013 14:53:13 +0200, Antoine Pitrou wrote:
> On Sat, 24 Aug 2013 14:46:32 +0200
> Stefan Behnel wrote:
> >
> > As I said, the only reason why the current implementation is there is
> > "because it's there".
>
> No. It works, it's functional, it fills an use case, and it doesn't s
Antoine Pitrou, 24.08.2013 14:53:
> it doesn't seem to have any concrete issues.
I don't consider closing your eyes and ignoring the obvious a good strategy
for software design.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Sat, 24 Aug 2013 14:46:32 +0200
Stefan Behnel wrote:
>
> As I said, the only reason why the current implementation is there is
> "because it's there".
No. It works, it's functional, it fills an use case, and it doesn't seem
to have any concrete issues.
Get over it, Stefan, and stop trolling
Antoine Pitrou, 24.08.2013 12:58:
> By the way, just know that Stefan tried to provide a patch that would
> better suit his API desires, and failed because ElementTree's current
> implementation makes it difficult to do so.
Absolutely. I agree that your current implementation is a hack that works
On Sat, 24 Aug 2013 15:57:50 +1000
Nick Coghlan wrote:
> On 24 August 2013 15:32, Stefan Behnel wrote:
> > So, to put it more nicely, I think this feature was added without the
> > amount of review that it needs, and now that I've given it that review, I'm
> > asking for removal of the feature an
On 24 August 2013 15:32, Stefan Behnel wrote:
> So, to put it more nicely, I think this feature was added without the
> amount of review that it needs, and now that I've given it that review, I'm
> asking for removal of the feature and a proper redesign that fits into the
> existing library.
FWIW
Antoine Pitrou, 24.08.2013 01:26:
> On Sat, 24 Aug 2013 00:57:48 +0200
> Stefan Behnel wrote:
>> ticket 17741 has introduced a new feature in the xml.etree.ElementTree
>> module that was added without any major review.
>>
>> http://bugs.python.org/issue17741
>
> As I've already indicated on the tr
On Sat, 24 Aug 2013 00:57:48 +0200
Stefan Behnel wrote:
> Hi,
>
> ticket 17741 has introduced a new feature in the xml.etree.ElementTree
> module that was added without any major review.
>
> http://bugs.python.org/issue17741
As I've already indicated on the tracker, I'm completely saturated
wit
37 matches
Mail list logo
