Importing SolidPython

SolidPython is a python library and as such it must be imported into an executable python script. This sounds straight forward, but in the history of SolidPython there have been several discussions about how to import SolidPython (SolidPython:#114, #44, #45). Therefor this page explains three different import styles of SolidPython and their pros and cons.

from solid2 import *

this is the "classic" SolidPython style (SolidPython:#114).

from solid2 import *

d = cube(1) - sphere(2)
d.save_as_scad()

The background of this style is the perspective, that SolidPython is something like OpenSCAD on steroids. SolidPython started -- and probably still is used quite a lot -- in small script files whose single purpose is to generate 3D models (like OpenSCAD). In this case, it's pretty handy to simply import everything from SolidPython into the global namespace and use all the SolidPython calls in a clean way without having any import overhead.

The drawback of this approach is that it contradicts with the standard python coding style and polutes the global namespace. If SolidPython is used in more complex environments with minor SolidPython fractions it might not be what you want.

The solid2 namespace does not collide with default __builtins__.

import solid2 as s

this is probably the style most corresponding to the python standard, but -- at least for my view -- creates less readable and clean code.

import solid2 as s

d = s.cube(1) - s.sphere(2)
d.save_as_scad()

Pros: corresponds to python standard

Cons: you always have to type and read a redundant s.

from solid2 import ...

a tradeoff and an alternative -- but I think less convenient -- style is to explicitly import every single identifier you want to use.

from solid2 import cube, sphere

d = cube(1) - sphere(2)
d.save_as_scad()

Pros: you only import into the global namespace what you want / need

Cons: import overhead