On Mon, 4 Apr 2022 at 16:56, Ben Rudiak-Gould <benrudiak@gmail.com> wrote:
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...
How often do you ACTUALLY need them to be local to a module? When is this ever a concern?
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".
You can already do that. Just import the appropriate terms from pint. I notice that people aren't doing it very much though - maybe because "1*ampere" is too clunky.
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.
That's a massive massive assumption, not supported by the way people work with complex numbers. Why is the square root of negative one special, if all other constants can be imported from modules?
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've used them frequently for working with curves on planes. I don't have any Python code to hand, though, since my latest such project needed to run in a web browser. It would have benefited significantly from Python's complex number support, though.
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.
Yeah, I thought about that possibility and the implications of requiring that unit-handlers be pure functions, but it might have other consequences not worth accepting. That can be an orthogonal discussion. ChrisA