solid2.extensions.bosl2 collides with python builtins

[taliesin]

from solid2.extension.bosl2 import *
s = sum([1, 2, 3])
print(type(s))

outputs <class 'solid2.extensions.bosl2.math.sum'>

One can workaround

import solid2.extension.bosl2 as b2

but this is pretty inconvenient.

The bosl2.math functions could check if the passed type is of their concern and forward to the standard functions otherwise?!

[jeff-dh]

hmmmmm see #44 I'll think about it.....

…

On Fri, 29 Sep 2023 12:33:54 -0700 taliesin ***@***.***> wrote: ``` from solid2.extension.bosl2 import * s = sum([1, 2, 3]) print(type(s)) ``` outputs <class 'solid2.extensions.bosl2.math.sum'> One can workaround ``` import solid2.extension.bosl2 as b2 ``` but this is pretty inconvenient. The bosl2.math functions could check if the passed type is of their concern and forward to the standard functions otherwise?!

[taliesin]

BTW 'list' is also hit, where type checking probably won't work.

[jeff-dh]

>>> from solid2.extensions import bosl2
>>> set(dir(bosl2)) & set(dir(__builtins__))
{'all', '__spec__', 'slice', 'complex', 'list', 'sum', '__doc__', 'any', '__name__', '__loader__', 'format', '__package__'}

so it's all, slice, complex, list, sum, any and format

Up until now, I think we need to rething importing bosl2 (and maybe solid2 itself). Your "workaround" might be the solution.
Another solution would be to explicitly import every single entity used from bosl2:

from solid2.extensions.bosl2 import cuboid

This seems inpractically but using a lsp this could also be feasible.

[jeff-dh]

Another solution would be to strip the bosl2 extension:

>>> from pprint import pprint
>>> intersect = set(dir(bosl2)) & set(dir(__builtins__))
>>> modules = set(bosl2.__getattribute__(n).__module__ for n in intersect if not n.startswith("_"))
>>> pprint(modules)
{'solid2.extensions.bosl2.lists',
 'solid2.extensions.bosl2.math',
 'solid2.extensions.bosl2.strings',
 'solid2.extensions.bosl2.utility'}

All these parts of the library sound to me kind of useless in Solidpython anyway, but I'm not sure..... anyway they could be imported explicitly if needed....

[taliesin]

I think it's probably the best way to import 'as', otherwise you'll end up hunting symbols when bosl2 progresses.
Some things are a bit opaque though, as there is a openscad cylinder and a bosl2 cylinder, the latter understanding keywords like anchor.

Probably the solidpython examples should be rewritten avoiding the 'from ... import *' style. This will prevent beginners from stumbling over these kinds of errors. They are not easily tracked for python beginners.

[taliesin]

Nice work, if the list of imports gets too long, the alternative
import solid2.extensions.bosl2 as b2
is acceptable as well and pretty much inline with numpy as np, for instance.

Thx for the work.

[jeff-dh]

https://github.com/jeff-dh/SolidPython/wiki/Importing-SolidPython

#46

[jeff-dh]

Hmmm, that was to fast ;)

I'm still not happy with the collision of the bosl2 namespace and globals()... I'm still thinking about striping the critical parts from the bosl2 extension. So reopen.....

[jeff-dh]

I striped the math, lists, strings and utility modules from bosl2.std.

This will be published in a 2.1.0 version with some other backwards compatibility breaking changes.