Alexandre Brault writes: > On 2021-04-03 12:07 a.m., John wrote: > >> Visually this means I can identify each particular operation and its > >> relationship with the next term, then ignore it (visually track parts > >> that no longer matter for understanding the equation) and look at the > >> next parts: > >> > >> 1: b c f + d % e * g h - 2 / ** / > >> 2: b ____ d % e * g h - 2 / ** / > >> 3: b ________ e * g h - 2 / ** / > >> 4: b ___________ g h - 2 / ** / > >> 5: b ___________ ___ 2 / ** / > >> 6: b [___________ _____ **] / > >> > >> Along the way, I've understood each part, and its relationship with > >> the rest of the computation. > > b/((((c+f)%d)*e)**((g-h)/2)))
> Your very long postfix equation may or may not be more readable > than the infix version with parentheses, but I'd argue that neither > is more readable than a version decomposed in bite-sized operations > over multiple statements, each using a self-documenting variable > name. That, to me, is much more readable and fits much more within > the philosophy of Python code +1 That was my immediate reaction, too: This is what temp variables like ____, ________, ___________, ___, and _____ are for! Although I prefer giving them less opaque names. :-) I do love RPN for calculations, dc >> bc any day IMO. But for me, RPN is write-only. The advantage is that I can frequently do the calculation twice in dc in the time it takes to do it once and verify correct formula and no typos in bc. 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/YIGJYPF73NRYHR5RYC6MBJELITORFK64/ Code of Conduct: http://python.org/psf/codeofconduct/
