On Tue, 5 Apr 2022 at 00:48, Brian McCall <brian.patrick.mcc...@gmail.com> wrote: > > Asked and answered! > > > * There are an unlimited number of derived (non-SI) and compound units > > that people will want to use. > > Unlimited? You sure that problem can't be bounded? There are few things I can > think of that could bound this problem in a performance-friendly manner. > > In terms of the internal representation of units, the representation that is > use for machine calculations, there are only 7 units that need to be > supported. Everything else is a product of powers of these 7 units. So you > can represent every combination with 7 counters. And those counters do not > need to have lots of bits. If you're using units in a way that leads to > meters**255, then you might have a bug in your code, or you might be doing > something that doesn't really need units. 4-8 bits are enough to store the > powers of the 7 SI quantities (4-8 bytes). Translating those 7 quantities to > the few hundred standard derived units can be handled by higher level > libraries, which may still require counters of multiple types of units > depending on the level and breadth of support being maintained. >
That would only be true if we had infinite-precision numbers. You can't simply store "this is two lengths divided by a time" and expect everything else to work perfectly. > > Having a single interpreter-wide namespace for units will cause many > > name collisions. I expect that units should be scoped like variables > > are, with some variant of the LEGB (Local, Enclosing, Global, Builtin) > > scoping rules in place. > > Yes, yes, yes! The trouble with namespacing like this is that you need to be extremely verbose about which units you're using in which module. With a single interpreter-wide namespace, all you have to do is ask the SI module to register itself, and you're done, they're available. Is it really that much of a problem? Tell me: How often do you REALLY expect to have collisions within an application, but in different modules? YAGNI. 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/BDVJ5KURCQUH3J3XYCYZSIJ7GBB3K26S/ Code of Conduct: http://python.org/psf/codeofconduct/
