Steve Howell schrieb:
On Nov 21, 4:07 pm, MRAB pyt...@mrabarnett.plus.com 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
On Sun, Nov 22, 2009 at 4:50 AM, Diez B. Roggisch de...@nospam.web.de wrote:
Steve Howell schrieb:
On Nov 21, 4:07 pm, MRAB pyt...@mrabarnett.plus.com 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?
On Nov 22, 7:55 am, Simon Forman sajmik...@gmail.com wrote:
On Sun, Nov 22, 2009 at 4:50 AM, Diez B. Roggisch de...@nospam.web.de wrote:
Steve Howell schrieb:
On Nov 21, 4:07 pm, MRAB pyt...@mrabarnett.plus.com wrote:
I don't see the point of EvalNode and PrettyPrintNode. Why don't you
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
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
On Nov 21, 4:07 pm, MRAB pyt...@mrabarnett.plus.com 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
On 22 Nov, 00:07, MRAB pyt...@mrabarnett.plus.com 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
On Nov 21, 4:33 pm, Richard Thomas chards...@gmail.com 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
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,