'import *' is not a recommended practice

[rockstorm101]

Documentation tells the user to use from solid import *. Which a practice that is currently discouraged [1][2]. Am I missing some good reasoning for doing this? Otherwise, would you accept a PR in the lines of suggesting something like import solid as sp?

[etjones]

Yeah, in other Python code I write, I'd definitely frown on * imports. Here's my rationale for using the pattern in SP and why I'm not sold on switching the idiom out.

If I were using SP in part of a bigger program with the geometry as a separate feature, I'd likely import solid as sp like you say. But pretty much all SP code I write (and, I suspect, that most people write) is just for a single purpose: geometry creation. If that's the case, namespacing all of your function calls seems to get in the way and decrease program clarity. Check out these two identical pieces of geometry:

# From examples, at https://github.com/SolidCode/SolidPython/blob/master/solid/examples/basic_geometry.py
from solid import *
left_piece =  union()(
    translate([-15, 0, 0])(
        cube([10, 5, 3], center=True)
    ),
    translate([-10, 0, 0])(
        difference()(
            cylinder(r=5, h=15, center=True),
            cylinder(r=4, h=16, center=True)
        )
    )
)

And see this with the recommended python import style:

# With namespaced import
import solid as sp
left_piece =  sp.union()(
    sp.translate([-15, 0, 0])(
        sp.cube([10, 5, 3], center=True)
    ),
    sp.translate([-10, 0, 0])(
        sp.difference()(
            sp.cylinder(r=5, h=15, center=True),
            sp.cylinder(r=4, h=16, center=True)
        )
    )
)

To my mind, the code in the first snippet is a lot clearer. Do you disagree?

[rockstorm101]

I see and completely understand your point. If this is the reason for suggesting import * then I guess I'm fine with it. (And yes, I agree, it is clearer that way, and faster and easier to write)

In all honesty I just started playing with this library so I'm not a long time user. However I've already found some downfalls to that practice such as having to name the function import_ instead of the more intuitive import. not being able to use __version__ to determine SolidPython version being used and specially the utils submodule defines several too common names that users might easily clash into by mistake (screw, nut, left, right, Green,...)

Anyway, I see your point. I guess it is not such an easy trade-off.