[zelphirkalt]

This sounds like they had people working on that code before, who had no clear picture of making a consistent interface, even if only by convention. Basically one should always default to standard SI units, or let the type system guarantee it, or in lack of such a system write comments explaining things, such as units and perhaps even give variables appropriate names indicating the unit. Another option would be using libraries, which take care of calculating with units and checking the units given.

Hope you can fix it. However, be prepared for other kinds of issues, which arise when there was not much discipline in writing the code.

[dagw]

who had no clear picture of making a consistent interface, even if only by convention.

There are few conventions that are consistent across domains. As a concrete example I worked on a code base where functions from some libraries wanted angles as radians and the others wanted them as degrees. Both where internally consistent and followed all the relevant conventions for their domain, however when they intersected it was a pain.

[lolive]

Just to open up the discussion, I am looking at the FMI [1] standard as a way to describe the interface of different block codes. And then try to generate the FMI description from static analysis of the Python function definitions.

That’s my current plan of study. But as I said earlier, I have some background in static typing in Java, and I might find the current state of the art in Python not to be adapted to my idea.

[1]: https://en.m.wikipedia.org/wiki/Functional_Mock-up_Interface

[macintux]

Something that seemed common in Erlang, but less so in Python, was to annotate numbers using tuples. If you used both radians and degrees in a single code base, they’d be passed around as named tuples.