On Mon, Apr 04, 2022 at 04:22:25AM -0000, Brian McCall wrote: [Chris] > > Part of the problem here is that Python has to be many many things. > > Which set of units is appropriate? For instance, in a lot of contexts, > > it's fine to simply attach K to the end of something to mean "a > > thousand", while still keeping it unitless; but in other contexts, > > 273K clearly is a unit of temperature.
Python is a programming language. I think we can require a certain minimum level of strictness, and reject ambiguity. Please read the Frink FAQ, especially the part about DWIM: https://frinklang.org/faq.html K means Kelvin, end of story. We don't need to support informal use or slang out of the box. But if units are scoped, like variables are, then people who really, really want K to mean 8192 bits can shadow the unit database with their own. > Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should > it evaluate to 1? I'd much rather it evaluate to 1 There are only two reasonable ways to parse that, depending on precedence of units and operators: * (2.54 inches) / (1 cm) = 6.4516 (dimensionless) * (2.54 inches / 1) * cm = 6.4516 cm**2 (or 1 square inch) If there is a third way, I can't think of it. In any case, I don't see how you can get 1. Maybe you mean 1 inch per 2.54 cm? This is why we need unit management :-) -- Steve _______________________________________________ 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/XV3QHOCQT47E3GYE4IMT2OK54MDTBGQS/ Code of Conduct: http://python.org/psf/codeofconduct/
