division

[Sean Ross]

"Steven Taschuk" <staschuk at telusplanet.net> wrote in message
news:mailman.1056478722.23433.python-list at python.org...
> You need the values produced by + etc. to be myints as well;
> merely inheriting the arithmetic methods from int is inadequate,
> since these methods return ints.  So you need to extend __add__,
> __sub__, __radd__, ...
>

Sure.
It was never my intention to produce a complete solution for the OP's
problem - it wasn't that interesting to me. I offered a quick hack to show a
way they could go about solving their particular problem *in the way that
they had set out to do so* (should they choose to continue in that manner).
I did not suggest that my solution was complete, optimal, or correct (in
fact, I indicated the opposite). This was just a possible avenue to explore.
If they chose to explore this route, then yes, they'd have to do as you
suggest, and hopefully, they would come to realize that, and perhaps learn a
few things along the way. Regardless, you're correct to point out the
shortcomings to this approach. So, thanks...heh

> Expressions are pretty easy to parse and evaluate, btw; it seems
> to me simpler to write your own parser/evaluator, rather than
> using eval.

Yes. I suggested the OP use SPARK, which has some example code for parsing
and evaluating expressions that use only addition and multiplication. It
should be fairly uncomplicated to extend that code to handle subtraction and
division, and to do so in a manner that complied with their requirements re:
division in particular. However, if they weren't interested in doing so,
they could still try to do what they want using the method I suggested (with
your additional specs). However, I also mentioned one other issue they'd
have to address if they chose to use the 'myint' approach; namely, that
they'd have to be able to ensure that the expressions typed in by their
users only ever included ints, and not floats. Beyond that, they'd also need
to ensure that the only other characters were (,),+,-,*,/, and that all of t
he expressions were well-formed. Which is *why* it would be simpler to make
a parser/evaluater - since they're pretty much going to have to parse and
evaluate the strings anyway to ensure that those strings are suited to their
purpose (and to handle them appropriately when they are not). Just feeding
in possibly arbitrary strings to eval and crossing your fingers that
everything will work out the way you've planned is a recipe for
disappointment.