Raymond Hettinger added the comment: Perhaps minds are already made up, but this may be the last chance to say that I think that this shouldn't go forward.
* The push to use of "tau" has the flavor a political fad or wishful thinking that may or may not succeed. The math module should only implement established practice. * Since not everyone knows or uses tau, its use would tend to make code less clear. As a reviewer, I would ask that code like "from math import tau" to be changed to "from math import tau as twopi". The latter is more clear to most users (how many people would recognize "tau * r" when it occurs in the middle of a larger expression?). * I've surveyed engineers in my recent Python courses (often with Physics, EE, MaterialScience, DSP, or CompSci backgrounds and not a single one of them had heard of this constant). * If people really wanted this, we would be seeing more cases of "tau = 2.0 * math.pi" in code. Google searches and Github code search shows that this is very rare. * It is already trivial to write "tau=2.0*pi" so why bother? * Adding mysteriously named constants degrades the usability of the math module where many of the tools are currently self-evident but not all ( tau is a number, gamma is a function, and what the heck is a frexp?). * Also, the name "tau" is already used for other purposes in various contexts (shear stress, proper time in relativity, torque, tau lepton, optical depth in astronomy, time contacts in RC circuits, etc). If needed, I can survey the audiences at the upcoming SF PyData conference and the SF PyBay conference to see if any of the participants have any clue what this is about and whether they would support the addition. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12345> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
