On Nov 22, 7:55 am, Simon Forman wrote:
> On Sun, Nov 22, 2009 at 4:50 AM, Diez B. Roggisch wrote:
>
>
>
> > Steve Howell schrieb:
>
> >> On Nov 21, 4:07 pm, MRAB wrote:
>
> >>> I don't see the point of EvalNode and PrettyPrintNode. Why don't you
> >>> just give Integer, Sum and Product 'eval' a
On Sun, Nov 22, 2009 at 4:50 AM, Diez B. Roggisch wrote:
> Steve Howell schrieb:
>>
>> On Nov 21, 4:07 pm, MRAB wrote:
>>>
>>> I don't see the point of EvalNode and PrettyPrintNode. Why don't you
>>> just give Integer, Sum and Product 'eval' and 'pprint' methods?
>>
>> That's a good question, and
Steve Howell schrieb:
On Nov 21, 4:07 pm, MRAB wrote:
I don't see the point of EvalNode and PrettyPrintNode. Why don't you
just give Integer, Sum and Product 'eval' and 'pprint' methods?
That's a good question, and it's the crux of my design dilemma. If
ALL I ever wanted to to with Integer/S
Steve Howell wrote:
My objection to the interface you describe is that Node defines the
type of operations that can be done to it by third-party code, which
is something that I cannot predict
I think you have the right idea with a mapping from node
classes to implementations of operations, but
On Nov 21, 4:33 pm, Richard Thomas wrote:
>
> This looks more structurally sound:
>
> class Node(object):
> def eval(self):
> raise NotImplementedError
> def pprint(self):
> raise NotImplementedError
>
My objection to the interface you describe is that Node defines the
type of o
On 22 Nov, 00:07, MRAB wrote:
> Steve Howell wrote:
> > I have been writing some code that parses a mini-language, and I am
> > running into what I know is a pretty common design pattern problem,
> > but I am wondering the most Pythonic way to solve it.
>
> > Basically, I have a bunch of really si
On Nov 21, 4:07 pm, MRAB wrote:
>
> I don't see the point of EvalNode and PrettyPrintNode. Why don't you
> just give Integer, Sum and Product 'eval' and 'pprint' methods?
That's a good question, and it's the crux of my design dilemma. If
ALL I ever wanted to to with Integer/Sum/Product was to ev
Steve Howell wrote:
I have been writing some code that parses a mini-language, and I am
running into what I know is a pretty common design pattern problem,
but I am wondering the most Pythonic way to solve it.
Basically, I have a bunch of really simple classes that work together
to define an exp
I have been writing some code that parses a mini-language, and I am
running into what I know is a pretty common design pattern problem,
but I am wondering the most Pythonic way to solve it.
Basically, I have a bunch of really simple classes that work together
to define an expression--in my oversim
