HEAR HEAR! BUT- SI units isn't enough. Engineers in the US and Canada (I have many colleagues in Canada and when I ask they always say: we pretend to use SI but we don't) have all kinds of units.
Give us native, customizable units, or give us death! Who's with me??!! ... .... I'm kidding to a degree but I did feel a swell of excitement as I read this response. :) The libraries out there- pint is probably the biggest one- have filled those gap as much as they can, but there are so many shortfalls... 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. I was just on an interview call yesterday for a senior engineer role at a large multinational earth works engineering firm and we spent 15 minutes talking about software and what we see coming down the road when it comes to the need for our discipline to grow in its software creation capabilities. 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. I don't know what the solution is. I'm looking to you software engineers, you true geniuses and giants of your fields, to figure that out for me. But once you hand it to me I promise I will evangelize it to the ends of the Earth. On Sun, Apr 3, 2022, 2:56 PM Brian McCall <brian.patrick.mcc...@gmail.com> wrote: > *SOAP BOX WARNING* > > It's not often that I would say that C++ is easier to read or more WYSIWYG > than Python, but in this case, C++ is clearly well ahead of Python. 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, ev > en 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. > > If you had asked me twenty years ago if I thought units should be a native > part of any programming language, I would have said absolutely - because in > my youthful ignorance I had no idea what it would take to make such a thing > work. Five years later, I would have said "not worth it". Now I'm back > where I started. 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? > _______________________________________________ > 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/TN2QSIKR4RT6D62FKHD5M44WV6LMSVKY/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/RZNRQUDIORSMJQU27NUTBHR2ZR4H7ULC/ Code of Conduct: http://python.org/psf/codeofconduct/
