Back in my original post, I pointed out that engineers and scientists in their modern day workflows are expected to have basic programming language skills, and are expected to use those skills when pre-packaged software solutions leave gaps in their workflows, but they are explicitly told that they are not "paid to write code", leading to bad programming practices and wasted hours and (unpaid) overtime resolving issues that could have been avoided if there was an implementation of scientific and engineering units that was too easy use to be ignored. This is a problem that I have run into dozens of times, and at more than place.
So yes, I am thinking about the real world. This is not an ivory tower fantasy. If a baker is writing python code, it's either a hobby or something that they plan to sell or are getting paid to do. Inventory systems have their own concept of units. But they also have dedicated teams of software engineers to handle whatever conversions and representations they need, and will continue to do so with unitless quantities. As I said originally, there is a real-world need for native or like-native support for standard scientific and engineering units is there, and it is growing. The only question is, should Python provide a solution? I can see that your answer is no, because it doesn't meet the needs of the bakers. I don't expect everyone to see updating or creating a new programming language to be the answer. But, no offense, the reasoning you have given for your opinion is not something that I can take seriously. _______________________________________________ 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/EV2WZVGLY5RUWZZ5Z2GB5UEHXFLK5NGL/ Code of Conduct: http://python.org/psf/codeofconduct/
