*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/
