On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano <st...@pearwood.info> wrote:
> On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote: > > > And that's exactly why I think that the *concept* of units could be > > added to the language, with some syntax and low-level semantics, but > > the actual units themselves belong in libraries. > > +1 on that. > > I'm not even sure about the need for syntax beyond what we already have. > Yes, it would be nice to write: > > speed = 15 ft 3 in / 3 sec > > but is it really so painful to use existing syntax? > > speed = (15*ft + 3*in) / (3*sec) > > I don't think so. > > > -- > Steve > The motivation is much more than just being able to not have the * symbol (though all things being equal it would be nice). I think I've mostly disagreed with Brian McCall on just about every DETAIL he has expressed regarding what "language level unit system support" ought to look like, but he had it right in his first post that spurred this discussion. I'll quote bits of it: On Sun, Apr 3, 2022 at 2:56 PM Brian McCall <brian.patrick.mcc...@gmail.com> wrote: > ...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. > > I get the sentiment that Python, or programming languages in general, are > not meant to deal with units. From the perspective of a computer scientist, > I can understand why this would be seen as a level of abstraction too high > for programming languages and core libraries to aspire to. But from the > perspective of a scientist or engineer, units are a CORE part of language. > 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" knows the sinking feeling and the red > flags raised when your answer comes out in the wrong units. > > There has also been a shift in the expectations of scientists and > engineers regarding their programming capabilities. A generation ago, a > good many of them would not be expected to use their computers for anything > more than writing documents, crunching numbers in a spreadsheet, or using a > fully integrated task-specific application for which their employer paid > dearly. These assumptions were codified in workflows and job descriptions. > Today, if your workflow, especially in R&D, has a gap that Microsoft Office > or task-specific software doesn't solve for you, then you are pretty much > expected to write your own code. Job postings for engineering roles (other > than software engineering) regularly include programming in their required > skills. Software design, on the other hand, is rarely a required or hired > skill. And even though these scientists and engineers are required to know > how to program, they are almost never *paid* to write code. Spending any > more time than needed writing code, even if it is to fill a critical gap in > a workflow, is seen as a negative. So software design best practices are > non-existent. All of this leads to very poor practices around and improper > handling of an absolutely essential part of scientific and engineering > language - units. > > ...The lack of native language support for SI units is a problem for an > entire segment of programmers. Programming languages took a big step > forward in deciding that EVERYTHING is a pointer/reference, and EVERYTHING > is an object. They need to take another step forward to say that EVERY > number has a unit, including "unitless". Not having this language feature > is becoming (or already is) a problem. The question is, is it Python's > problem? And I said: 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.... > > 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. > Steven: I am telling you that there is a HUGE NEED and DESIRE for what we are talking about above. the need to automate design processes in the "i need you to get me a set of calculations and drawings for this complicated project to me, TODAY, mr engineer?" electrical, structural, chemical, industrial/manufacturing, mechanical, and general civil (environmental, water/wastewater, geotechnical, chemical, transportation) fields is monstrous. it said above it is "the next frontier". but it won't be unless these men and women get the tools they need. someone is going to fill the need. units are at THE CORE of that need. i think python should be the language we reach for. i have made python work for me as a civil engineer and been extremely successful with it for all the usual reasons: ease of learning and community backing that learning, the open source resources (libraries and applications), the momentum of the language, its ability to be a swiss army knife (need to transition to web? automate the boring thing? sure, easy). but i do not think the people in the disciplines listed above are flocking to python like they should. almost nobody in the PSF foundation surveys answers "civil engineer" when they take the survey (i do, every year!). it should be hundreds, maybe thousands. and a big big part is that using units is too hard. we need to make it easier. how? i don't know. i'm not software engineer. but i am telling y'all, it's too hard. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
_______________________________________________ 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/MK63QU7M2BLIA6A6QZAL2WOZN3JLGXEF/ Code of Conduct: http://python.org/psf/codeofconduct/
