I have trouble imagining situations in which SI units would help readability over scientific notation. On the one hand reading it always involves mental conversion to the exponents, so this is just an extra step. E.g. this equality is evident at a glance:
1e3 * 1e6 * 1e-9 == 1 This one would take me a few seconds, and I'd need to run it twice in my head to make sure I wasn't doing it wrong: 1k * 1M * 1n == 1 The more complicated the expression, the bigger the cognitive advantage for numeric exponents. I think the OP is drawn astray by the utility of domain specific familiar dimensional units. 1MeV means something in a domain. So does 1ps. Or 1km. But really it's the units not the exponent that are helping us (plus knowing that our specific domain deals with dimensional quantities of a certain scale). But even past the ease of mental arithmetic, I don't see why one would use literals very often to start with. If they are constants, give them a better name! If they are variables, likewise. If it helps your domain, add the units to the *names*, e.g.: lightyear_m = 9.5e15 galaxy_radians = calculate_arc() dist_m = lighyear_m * galaxy_radians * arc_len That looks a lot clearer to me than sticking together raw numbers, however spelled. On Aug 25, 2016 2:56 AM, "Joao S. O. Bueno" <jsbu...@python.org.br> wrote: > On 25 August 2016 at 06:06, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 25 August 2016 at 09:54, Ken Kundert <python-id...@shalmirane.com> > wrote: > >> 1G -> 1e+09 > >> 1M -> 1e+06 > >> 1k -> 1e+03 > > > > While these suffixes are suitable for a scientific context, in a > > computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make > > just as much, if not more, sense (and yes, I'm aware of Gigabyte vs > > Gibibyte). > > > > If "1M" were a legal Python literal,. I would expect a lot of > > confusion over what it meant - to the extent that it would hurt > > readability badly. > > Paul > > > So, the idea of adding fixed sufixes to the core language I regard as > awful - due to these and other considerations - > But maybe, oen thign to think about is about "operatorless" > multiplication - jsut puting two tokens side by side, which currently > yieds a Syntax Error could call `__mul__` > (or a new `__direct_mul__` method on the second operator. > > That would enable a lot of interesting things in already existing > packages like SymPy - and would allow a "physics measurements" > packages that would take care of the ideas on the starting of the > thread. > > I certainly would be more confortable for mathematicians and other > people using Python in interactive environments such as iPython > notebooks. > > But other than having this as a multiplication, I am against the whole > thing. > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/