As for the incrementalparser/read thing - I wouldn't do that - I would
just pull BufferSegments off the "DataQueue" and feed their payloads
directly to the IncrementalParser via feed. The use of read is just a
bunch of extra overhead. feed appears to be a perfectly acceptable public
method.
-Gabe
On 1 Mar 2002, Sean Allen wrote:
> -----Forwarded Message-----
>
> From: Sean Allen <ze...@wo...>
> To: Sean Allen <ze...@wo...>
> Subject: Re: [Pybeep-devel] updates: scheduler and stuff
> Date: 01 Mar 2002 11:17:10 -0800
>
> On Fri, 2002-03-01 at 10:53, Gabe Wachob wrote:
>
> > Only two were broken and they were trivial fixes. Maybe this means we are
> > behind on our test writing!!!
> Yes, yes we are....
>
> > I was hoping you'd volunteer! I'm a terribly messy coder and I really like
> > having someone else's structure to work against. So please have at it..
> > just let me know what your style guidelines are.
> >
> I think a simple place to start here would be Guido's python style
> guidelines.(http://python.sourceforge.net/peps/pep-0008.html) make sense
> to work in a style used in the core libraries and I normally try to
> follow these.
>
> > I was thinking the feed method on IncrementalParser (which just takes
> > string data) would obviate the need for a file-like interface. If you
> > look at the parse method, all it does is loop through the source parameter
> > calling read and passing the results to feed anyway... and even so, the
> > DataQueueStream has a read() method that would work just fine for parse (I
> > think).
> Ok.. cool, I'll look into this. So basically, we are going to work
> around the read() method and use it for all our parsing needs... off to
> the Incremental Parser source I go.... it was just throwing a wierd
> exception at me when I was doing some interpreter testing the other day.
>
> Sean
>
--
Gabe Wachob gw...@wa...
Personal http://www.wachob.com
CTO, WiredObjects http://www.wiredobjects.com
|
