Brian McCall writes: > 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.
According to you. I would like dollars and shares to be supported as well as perhaps "kg of apples" (vs "kg of oranges"). What is a unit? It is an attribute of a quantity that says how it may be combined with other quantities to produce more quantities. In some situations (determining whether I should have "driven the backroads so I wouldn't get weighed") I'm happy to ignore the commodities and add up the kg, but in others (making out the invoice) I don't want to multiply price of one commodity by the quantity of another. I'm sure there are other applications besides accounting and physics, and each will have its own idiosyncratic constraints on combining quantities, ie, its own units. > > 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! This is a job for ... Superlibrary! IOW, I'm with David. There may be a justification for supporting custom literals in the language, but really, in this it's just syntactic sugar for constructing an object of a derived class (ie, a number, unit couple) and should be designed that way. I think it's probably way overkill to support quantities (ie, numbers with units) as a primitive type in the language. For many computations, a library will be fast enough. For iterative computation or large data sets, I would guess it's very rare to want to check compatibility of units on every operation. Rather, for function calls you want to treat them like types of the actual arguments, and for vectorized computations, normally the whole vector will have the same units. And even if you did treat quantity as a primitive type, few existing programs are likely to ported to use the feature (and if the guts are some ancient Fortran library, they can't be, you'll have to strip the type information off the numbers before operating on them anyway). _______________________________________________ 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/UO6EEVY6KULGDBI5MKJAXNNUYCN6ESFO/ Code of Conduct: http://python.org/psf/codeofconduct/
