Fix bad imports that prefer a global file called 'solidpython'

[eric-wieser]

implicit relative imports are a bad idea, and unless you really want python 2.4 support...

[etjones]

This is an awfully big change. Can you expand at all on your motivation for A) putting live code in init.py, and B) splitting the main solidpython file into multiples?

In general, I agree about implicit relative imports. I don't like opening an __init__.py file and finding that it's doing things I didn't know about. However, there are a couple goals I had for this package that the init magic helps accomplish:

1. I wanted everything stored under the solid package, and
2. I wanted to be able to import all OpenSCAD functionality in one single line that would be the same in all code.

The current system does this, albeit with some tricky magic involved. I'm not convinced that your proposed solution makes the conceptual layout any cleaner, but I'm willing to hear some more about why you laid things out the way that you did.

[eric-wieser]

1. your motivation for putting live code in init.py

   The structure you have at the moment is basically:

   mymodule/
       __init__.py  # contains `from .actuallymymodule import *`
       actuallymymodule.py
   

   Which means when you import and print a type, you get a messy long name:

   >>> from mymodule import MyClass
   >>> MyClass
   <class 'mymodule.actuallymymodule.MaskedArray'>
   

   This submodule does not add any useful hierarchy, since it's not clear whether things should be in it or elsewhere anyway.

   Of course, you'll note that I still kept most of the code out of init.py anyway. The things that are left are only left because
   I couldn't think of a suitable place to put them.

2. splitting the main solidpython file into multiples?

   I did this to improve readability. It's easier to understand loosely-coupled systems, which can be broken into a few smaller pieces with a few crossovers, rather than one large file with no clear indication of which bits depend on other bits.

   It's also useful from a git diffing standpoint - you can immediately see which components have been modified before you look at the line-by-line diff

   _builtins just contains huge amounts of documentation and barely any code. Putting this in a separate file makes it easier to navigate the rest of the code.

I don't think any of this change affects how user code appears, and they can still import * as normal.

[eric-wieser]

Either way, this is totally unmergeable now. I'll try to rebase a few parts

[etjones]

I just took a look at solidpython.py and I think you've convinced me about breaking things up. _builtins.py especially makes sense as its own module, since there's so little logic there. I haven't played with this at all, but do you think it's feasible to get the current contents of your __init__.py (py2openscad(), etc) into a separate module (or _render.py?) so that __init__.py only contains imports?

[eric-wieser]

@etjones: PR incoming with _builtins.py renamed as objects.py, and everything else untouched

[eric-wieser]

Closing this since it will conflict forever