It occurs to me it's a syntax error everywhere to put two
potentially-calculable terms in a row with nothing between them, e.g.:
```python
a = b c
mylist = [x 6 for x in y if "a" in x]
```
Unless I'm missing something, this makes it relatively easy (from a
syntax perspective; writing a parser r hard) to detect such:
```python
a = b c 6 ** + 5 /
mylist = [x 6 + for x in y if "a" in x]
```
This is a bit less ambiguous and simpler to write (and easier to read,
caveat you have to know *how* to read it) when dealing with
complicated expressions with a lot of parenthesis—a use case I
automatically want to dismiss despite always running into this
immediately.
```python
# tl counts from sleep_us()
print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" %
(i,c,1000/(tl/(1000*i)) if tl > 0 else 0))
# RPN
print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" %
(i,c, 1000 tl 1000 i * / / if tl > 0 else 0))
```
I took the following steps in writing this:
* 1000 /
* 1000 tl / /
* 1000 tl 1000 i * / /
The first is the incomplete operation 1000 / <something>
The second adds the divisor between the term (1000) and the operator
(/), which is again going to be tl / <something>.
The third adds the divisor there, 1000 * i, between tl and its operator.
Reading it back is easy enough: scan until finding an operator and
take the two terms to the left, e.g. u=(1000*i), then v=tl/u, then
w=1000/v. You could also read "1000 tl 1000 i * / / gettime() +" by
further doing x=w+gettime() ... it's read directly in sequence.
From my perspective, one of these is harder to read than the other,
and no amount of carefully-placed white spaces is going to replace a
piece of scrap paper to untangle the order of operations. You can
break it down to intermediate steps, but that can make it difficult to
follow a complex calculation.
Downsides:
* Have to actually implement it in the parser
* If almost nobody uses it, still have to maintain it until the end of
time for compatibility
* While it takes all of 30 seconds to learn, it's not obvious what in
the heck you're looking at if you've never seen it
* While it's easier to revise complex calculations and at times more
readable, infix exists for a reason. RPN is built from the outside in
for nested computations (although often that also involves going back
and forth to add extra parenthesis while writing infix, rather than
simply typing it out left to right in one go)
Things to not do:
* Mix-and-match single expressions e.g. 6 2 (3 * 4) + *, 6 * 2 3 4 * +
While the first looks innocent enough, without the parentheses it
becomes 6*(2*3 + 4). The second is just unreadable.
* Reverse polish function calls e.g. 3 4 + str()
no, just no
* Prohibit infix in a call e.g. 3 4 getdata(n + 2) + *
This isn't ambiguous, nor is it more difficult to read or parse
Thoughts?
_______________________________________________
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/XXAWV6GUSQFDM5GAJ7P32GBK3EYVLMNK/
Code of Conduct: http://python.org/psf/codeofconduct/
