Clarification on degrees()/radians()

[Cabalist]

Out of curiosity how do solid.utils.radians and solid.utils.degrees differ from math.radians and math.degrees?

[etjones]

I sure hope there's no difference! I suspect that the rationale at the time was either a) I didn't know about math.[radians|degrees], or b) I was hoping to include everything you might need for normal use in a single from solid.utils import * import. In general, there are great reasons to avoid * imports, and in more general-purpose code I definitely do. In SP/Scad code, I've almost always only been doing one thing, solid modeling, and the convenience of having everything a user would need in the top-level namespace seemed like a reasonable tradeoff for the possibility of name clashes or uncertainty about where a given method came from.

Somebody recently wanted to do away with the from solid import * pattern, and for that reason I declined. With the stolen radians/degrees functions, I don't feel so strongly.

[Cabalist]

I'd be inclined to remove these and point the internal code at the math library. This is a simple example but there are places where reimplementing math can be hazardous.

Fun fact: Tau has been in the math library since 3.6. ;) Epsilon is in the stdlib as well is probably not the value you are looking for.

---

To go off topic on this issue: I think if the inclination is to keep from solid import * then the from .objects import * needs to be replaced in solid.__init__.py with an explicit API list (i.e. from .objects import cube, ...). And in my opinion it should include only explicit SolidPython code.

Any time saving that less typing from import * has afforded over the years has been negated tenfold by numerous hard to debug import issues. We've run into at least one in this code where the removal of an unused import statement in objects.py broke unrelated setup code in the test suite for use().

[Cabalist]

And I guess to add to this since I slept on it.

Succinctly: import * is fine when writing personal code with a well designed library. But I personally don't believe it has a place in a library or production code. But it is great for just messing around. :)

[etjones]

I think you're absolutely right about this. I've got no problem removing the redundant math functions in favor of their official originals. And precise explicit imports in the __init__.py code (and anywhere else I've been doing * imports in the library) is a very good idea. As I said, I don't want to remove the capacity for end users to import everything all at once, but there's no advantage to that kind of sloppiness in the library itself.