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?