On Sun, Apr 3, 2022 at 10:10 PM Chris Angelico <ros...@gmail.com> wrote:
> On Mon, 4 Apr 2022 at 14:13, Ricky Teachey <ri...@teachey.org> wrote: > > What does that idea bring other than being able to say 5.0m > [...] instead of 5.0*m [...]? > > A large amount of clarity, readability, and namespacing (you don't have to > pollute your global namespace with a large number of single-letter names, > since these tokens will ONLY have meaning when immediately following an int > or float literal). > I feel like one of the biggest sticking points in this thread is that people are arguing for a new kind of global scope just for units, and the sole reason seems to be that they want short names for them. The register_numeric_suffix idea would create a true global namespace, independent of the module system. That seems like a bad idea: libraries should be able to use their own units internally without potentially breaking other libraries. Units should be local to each module. You need a way to import them into your module's unit namespace. You might want to import only some of the units exported by a unit provider... There is already a solution to all of these problems. All you have to do to be able to use that solution as-is, instead of introducing a large amount of new complexity to the language, is give your units names like "ampere" instead of "A". I don't think that would be much of a problem. How often will explicit unit names show up in a program? Maybe you'll multiply by 1 meter in one place when reading a CSV file, and divide by 1 meter when writing. You probably won't write 1.380649e-23 J/K inline, even if you only use it once; you'll assign it to k_B or something. Or just import it from a physics-constants module. If you're doing a-la-carte computations at the interactive prompt, you can "from units import *" for convenience; the official docs already advise "from math import *" in that situation. in theory, we could just have a variable called "j" (or "i" if you prefer) > which you multiply by something and add something, and that's your > complex number. But it's cleaner to write "3+4j". > I would like to see examples of how complex literals are used in the wild. I feel like most will look like (4086.184383622179764082821 - 3003.003538923749396546871j) (an actual example from mpmath.functions.elliptic), or are just ±1j. There's practically no situation in which you'd want a literal like 3+4j. Even crazy constants like those from mpmath are unlikely to appear in your code because most people aren't numeric analysts who write math libraries. I feel like the biggest benefit of the suffix j syntax is that it's recognizable as a foldable compile-time constant, so you can put foo+barj in an inner loop cheaply. mpmath has "3.1415926535897932j" in a couple places, which I suppose is for speed; it certainly isn't for readability. Python should have some generic solution for this problem, like C++ constexpr, but I don't know how to do it, and it's a different discussion. >>> 3 * ureg.meter + 4 * ureg.cm Same problem here: I don't believe that anyone would write that in a real program. How are libraries like pint actually used?
_______________________________________________ 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/VO6JTW742ENSAVO4U4LO6V5N5IZCDGB2/ Code of Conduct: http://python.org/psf/codeofconduct/
