> Agreed, this is just using Python as a glorified calculator. I understand > that this is just an example, but I *am* curious, is the bulk of what you do > simply calculations like this, or do your more complicated examples tend to > be more like actual programs?
I have never shipped code that would depend on these features. Code like this, including this exact formula, might sit in a script and be used to calculate normalization factors and feed into a noise model. That script might look at one complete concept that I want to test out in theoretical sense. In other cases, I'll make one or more of those quantities out to be variables that I pass in via command line or config file. This allows me to explore a system design space. I used to ship code when I worked in telecom ~15 years ago, and that was mostly C++. Units were not a concern. I shipped C++ and Python code 2-5 years ago at another company (startup) which did not require units, but I also did my feasibility assessments with stuff like this that did depend on units. > Given that the error was in the magnitude of one of the values, "magnitudes > are easily verifiable" doesn't really seem that correct... ... ah, I mean the mantissa, not the magnitude > Please can you explain this to me? I don't know what you mean by "get the > final answer", nor do I know how astropy.units is relevant. Units seems to be > a perfectly acceptable library without astropy, is that not the case? Am I mistaken, or is the units module no longer maintained? I could not find any documentation for it. Which is also a con. I honestly thought that "units" took on a new life as "astropy.units". > As has been mentioned, if you don't like "units." then "from astropy import > units as U" and use "U.ms" of "from astropy.units import ms" and use ms > directly. As an fyi, lots of single-letter variables are commonly used to match variables in physics and engineering equations. U and u are of particular importance in my field. > Don't use "import *" then, just import the names you need. Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯ > Maybe that suggests that there's room for a unified library that takes the > best ideas from all of the existing ones, and pulls them together into > something that subject experts like yourself *would* be happy with (within > the constraints of the existing language) Just to point out, I don't make this suggestion just for my benefit. I can handle all of the syntax limitations that I pointed out. I am in a somewhat unique position of having a BS in computer engineering, but I have worked for 10+ years now in the optics industry, along with physicists, electrical engineers, and mechanical engineers. I was taught in school all about OOP, data structures, all that stuff. But most of the people I know today who write code do not have any formal training in this area. There are varying ranges of comfort with things like logical indexing, dot-notation (which you and I take for granted) and functions as objects that can be returned by other functions. I have seen code that looks like spaghetti served in a bowl that was shattered and put back together with duct tape. And some of it is related to units. If I make suggestions like what you have made, the response I tend to get is "my code works". Which would be fine with me if I never had to use their code. Others who feel strongly about units, or dual threat CS/ECE types who have to work with self-taught programmers with physics or chemistry backgrounds may have other stories. _______________________________________________ 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/5VA3ESO4GVMCP6SCH76M2IUNILAVBPXF/ Code of Conduct: http://python.org/psf/codeofconduct/
