__str__ vs. __repr__

[Steve M S Tregidgo]

Fredrik Lundh wrote:
> Phil Hunt <philh at vision25.demon.co.uk> wrote:
> > How about:
> > 
> >    x = a + b + c
> >    x = (a + b) + c
> >    x=a+b+c
> > 
> > I'd guess these all produce the same bytecode.
> 
> footnote: the abc80 computer I mentioned
> in my earlier post had an extra byte code
> for this purpose.  users can buy that you
> add spaces and reformat their code, but
> they won't accept that you remove their
> parentheses...
> 

Two solutions:

(1) When regenerating the source, wrap every single binary op with
parentheses; the bytecode generated by (a+b)+c will also be generated
by ((a+b)+c), and at least the user's original bracketing will be
there too.  Looks very messy though.

(2) Use some intelligence in deciding where brackets need to go. 
Clearly if (a+b)*c was compiled into bytecodes, we would have to
ensure the brackets remained, but (a*b)+c uses extra brackets that
can be ommitted during the decompiling stage.

This second solution wouldn't be so hard -- the order of the
bytecodes tells us which ops come first, and so we'd just need to
bracket a nested op if the op that uses the result is of a certain
type (so if a BINARY_ADD applied to elements a+b and c, there would
be no need to introduce protective parentheses, but there would for a
BINARY_MULTIPLY on a+b and c).

Anyhow, since decompiling should mainly be used to recover lost code,
as long as the code works the issue of (orignally extraneous)
brackets missing isn't really a problem -- I for one would just be
grateful that I got my code back.  (And heck, if I actually noticed
that the odd bracket was missing from a thousand-line file, I'd
consider that I'd got a bit _too_ familiar with the code ;-)

Cheers,
Steve