John writes:
> Here's a question: is it possible to implement this with a Python
> module, or is that absolutely not a thing that can be done?
Yes, it can, or at least you could use MacroPy (not sure if that's
pure Python, if it is then you could implement in a module using the
same techniques).
> > > This is what temp variables like ____, ________, ___________,
> > > ___, and _____ are for! Although I prefer giving them less
> > > opaque names. :-)
> > Helps, but does spread the information out.
That's not a problem for reading the expressions themselves --
spreading out the information into meaningful (and thus nameable)
chunks is the point of the exercise. *Unless* you've got a pure
functional language. In that case you could be 436k away from the
beginning of the expression (that's the largest Java class I ever
encountered in the wild, and boy, was it wild).
I'd be more sympathetic if the issue was spreading out a suite of
statements, but even then, not very. I've never encountered code that
can't be understood if written in 24x80 chunks of Python, including
the relevant def lines and a couple of comments. If efficiency is
required (and achievable in pure Python!), inlining those functions
isn't hard, although it can be tedious. Very rarely is *naming* those
functions difficult.
YMMV, of course, but that WFM. (Note, I don't object to the proposal,
I'm purely talking about what WFM. I might object to you using it if
we were working on the same project, though. Depends on
circumstances. :-)
> > It also requires finding useful names, and there aren't always
> > meaningful names for intermediate steps.
Then those are the "wrong" intermediate steps. If you *really* need
to break there, then a meaningless name such as "__" is fine.
One practical problem with RPN is that one way to break up and "mark"
subexpressions *without* temporary variables is to use (physical)
newlines and indentation. With infix notation
(minuend # note: parentheses are idiomatic Python line
- subtrahend # continuation
+ multiplicand
* multiplier)
reads well and parses easily in-brain. But in RPN you have an
uncomfortable choice: put the operators at line endings (where you
will *not* normally be scanning in Python because syntactic keywords
generally come at the beginning of the line) or put them at the
beginning of the line (requiring scanning up the page to find the
operands and probably giving your brain a bit of WTF).
Even a programming language with Arabic or Hebrew keywords wouldn't
work well with RPN as far as I can imagine. Yes, you'd be scanning
down the right margin for syntax, but the RPN operators would end up
at the left margin! Or maybe in the middle of the line, depending on
how you interpret "BIDI" (any comments from those fluent in a BIDI
language?)
Could be "just my [lack of] imagination", of course.
> > Interesting that people find it write-only. I find it easier to
> > modify a complicated equation in RPN than algebraic because it's
> > easier to find precisely the part of the calculation I need and
> > insert the extra code.
As an applied mathematical economist, I work with obnoxiously
complicated equations a lot, but always factor out subexpressions and
give them names (to which the policy wonks frequently apply motivated
reasoning and conclude I proved exactly what they needed, c'est la vie
:-). I am not struck by reasons to dive into a complex expression and
modify it. I discover reasons to modify some relevant subexpression
instead. That's the way I *think* about such interative refinement
processes as well as how I *implement* them (ie, typically notated as
functions).
Maybe that's why I work that way with Python programs, too. I don't
know about your field, but in mine it's *very* unusual to encounter
expressions that aren't repeated in other contexts, and therefore
idiomatic ~= meaningful. Usually that subexpression is there because
it implements a domain concept. If I don't have a good existing name,
a neologism will do, and because the expression is an idiom, that
neologism has meaning to others in my field -- from the subexpression.
> > I'd honestly been considering if we should have taught RPN first
> > to give students a way to parse complicated algebraic equations
> > by rewriting them in a less-opaque form, but quickly realized you
> > never encounter anything more complicated than multiplying two
> > polynomials in an educational setting.
Complicated expressions are just complicated. I don't think it really
matters which way you teach. Either way you can't avoid the
complexity, and either way you have to parenthesize, either with
actual parentheses in the expression itself, or with increasingly long
underlines. :-) (I'm laughing at myself, because I think it's true
but I'm not 100% sure.)
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5OKD6GWUUN5SRDHT27XZMF73EVVGGFSA/
Code of Conduct: http://python.org/psf/codeofconduct/
