On Mon, 4 Apr 2022 at 16:56, Ben Rudiak-Gould <benrud...@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 _______________________________________________ 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/PC3CFLH5R4GGUYT3A5VCYCMMTHUHK6XL/ Code of Conduct: http://python.org/psf/codeofconduct/
