I'll start with some opinionated stuff, but possibly helpful attempts
to understand the requirements follows from about the middle of the post.
Ricky Teachey writes:
> [Brian McCall] had it right in his first post that spurred this
> discussion. I'll quote bits of it:
>
> > ...I have spent a fair amount of my own time, and I have seen so
> > many others' time wasted because command line or input fields do
> > not include units, or the inputs field units are accidentally
> > handled with different units, or units are not used at all.
This has zip-o to do with having quantity (number-with-unit) objects
as part of the language. It's all about parsing natural language, or
providing the user with sufficient hints about the expected input.
Ie, it's UI/UX.
> > I get the sentiment that Python, or programming languages in
> > general, are not meant to deal with units.
I have no idea where this came from. The plethora of units libraries
both on PyPI and in various folks' personal toolkits gives it the lie.
> > Anyone who has taken science or engineering classes in college
> > knows what happens when you turn in homework with missing units
> > in your answers - zero credit. Anyone who has worked out
> > complicated calculations by hand, or with the help of packages
> > like "units"
Oops, we just let the cat out of the bag. How hard it is to use the
units library? What is hard about it? Sure, it's an annoying amount
of setup, but do it once for your field and copy-paste it (or import
from your toolkit) and the only differences between using units and
having user-defined literals is typing * instead of _, and the
possible embarrassment of typing "cm_per_in = 1 * in / 1 * cm" and
getting units meters**2 (but you immediately know you did something
wrong).
> > ...The lack of native language support for SI units is a problem for an
> > entire segment of programmers.
This is the X Y problem. We'll all concede that units support is nice
to have, and if you want to consider the lack of units support to be
existential, fine by us. But you're going to have to do a tun of work
to show that it needs to be *native* support (ie, in the language),
that it requires new syntax.
> > They need to take another step forward to say that EVERY number
> > has a unit, including "unitless".
I disagree, but it's not open and shut -- I at least am open to
evidence of this claim. Suppose we do need that. Even so, it's not
clear to me that this shouldn't be handled the way we handle typing,
that is, by treating a quantity of 1 kg as being a different type from
1 m, and inferring types. (Example below.)
> The old engineering disciplines- mine (civil engineering), structural,
> electrical, etc- are the next frontier in the "software eats the world"
> revolution, and they desperately need a language with native units
> support....
Again, nobody has provided any foundation for the claim that they
*need* *native* support, except that C++ jumped off that bridge so
Python should too.
What follows are questions that need to be answered to implement the
feature well. They shouldn't be taken as "YAGNI".
> Python SHOULD be that language we do this with. It is awesome in every
> other way. But if it isn't DEAD SIMPLE to use units in python, it won't
> happen.
What does "dead simple" mean? Do you expect people to be using Python
as a calculator so that the majority of their typing involves literal
quantities (ie, numbers with explicit units)? Or is the more common
use case writing
def foo(v: Volume, d: Density) -> Mass:
return v * d
and have an I/O functionality that can convert strings or csv files to
Volume and Density objects, and Mass objects have a nice __str___.
Then in the rare case where you need to specify a quantity (eg,
demoing at the interpreter prompt) you have to write
foo(2.34 * m * m * m, 0.06 * kg / (m * m * m))
Is that too "difficult"? If it is, how about
m3 = m * m * m
foo(2.34 * m3, 0.06 * kg / m3)
By the way, this is possible right now, mypy will check it for you.
(Of course somebody must define the classes Volume, Density, and Mass,
and write the I/O and __str__ functions. But only the I/O is at all
hard.)
> a big big part is that using units is too hard.
I have no idea what you mean by "using units". Abstractly, yes, but
what programs are you going to write? Are they going to be littered
with literal quantities, as Brian's proposal for custom literals
suggests? Or is it just important that when you operate on some
quantities, their units are checked for compatibility, and results can
be easily checked for appropriate units if the programmer wants to?
Do people often confuse moments, energy, and torque in their
computations so that we need to distinguish them in our unit
libraries, or does that kind of thing happen so rarely that cancelling
SI units and prefixes wherever possible would give good enough
results? (Note that the "units as types" approach can prevent you
from substituting energy for torque.) In large data sets, are
variables polymorphic so that every value must be a quantity, or can
NumPy tag individual series with their type (= unit), and the values
can be just numbers?
_______________________________________________
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/VWDXMV4STRPK3XFTSFYBWZ64QBMUU4MN/
Code of Conduct: http://python.org/psf/codeofconduct/
