Re: [Pythonverse-devel] Proposed changes

[Andy Goth]

(oops, sorry Sean, forgot this is a *decent* mailing list that doesn't 
mutate the from or reply-to headers)

On Tuesday, March 19, 2002 3:26, Sean R. Lynch KG6CVV wrote:
> One way would be to just have the parser look for a method called
> cmd_<keyword> and then call that method with the whole string, allowing
> each method to do its own parsing. Each method could just call split on
> the string with the number of arguments it was looking for, and then
> convert on its own. Regular expressions just add more flexibility than
> we need. Ryoko was on the right track for doing a general parser, but
> the format that the server uses is restricted enough that we don't
> really need regular expressions for parsing. This is the method I'm
> leaning toward.

In the Tcl client, each protocol handler does all its own parsing.  As a
helper, it gets the server text in both one long string and a list of
strings broken at space characters, but this list is very easily generated
from the long string.  It's a little clumsy, but it works.

> The other way would be to use the existing regular expression-based
> parsing, but instead of using a tuple of conversion functions and a
> method pointer, use a string that gets compiled into Python code and
> execute the code with the matched groups in the regular expression
> assigned to variables. This is how I do parsing with FrogGirl, but
> that's because i needed the flexibility.

>From the perspective of the protocol handler, this simply rules.  But how
much more time does it take to set up the data?  I'd say, OpenVerse isn't a
busy enough environment to require shaving off this extra feature.

But, as you say, this extra feature actually takes almost as much typing as
having each function do its own parsing, so this kind of negates the gain.

> I was also thinking of maybe passing images as strings, which is a
> pretty standard way to represent images in Python, rather than having
> the client provide an image loading function. This would allow backends
> to support proprietary image formats without the frontends even needing
> any sort of image loader since all they'd need is a fromstring function.
> The disadvantage is that the backends would then need to depend on an
> image loading library even though the frontend's GUI library might
> already have an image loader.

A possible way to get around this dependency is to optionally pass the file
binary directly rather than decoding it first.  I don't think I'm being
very clear here, but I hope you catch my drift.

> Comments?

No, I have no comments to add.

--
Andy Goth  |  address@hidden  |  http://www.pengaru.com/~andy/
User has performed an invalid operation and will be terminated.