Closed HowManyOliversAreThere closed 6 years ago
So, given a list a
of OpenSCADObject
s, union()(a)
adds them all together. Since that feature already exists, and since I'm deeply skeptical of ever adding an integer and an object (even it it's a no-op), I'm hesitant to merge this. Can you think of a situation where using sum(a)
would be better than union()(a)
?
e.g., here's a unioned SCAD list, and the OpenSCAD it compiles to:
a = [cube(5), right(10)(cube(5)), right(20)(cube(5))]
unioned_list = union()(a)
print(scad_render(unioned_list))
yields:
union() {
cube(size = 5);
translate(v = [10, 0, 0]) {
cube(size = 5);
}
translate(v = [20, 0, 0]) {
cube(size = 5);
}
}
I would say that the sum(a)
implementation is more intuitive when you're already working with the +
and -
operators, rather than union()
s and difference()
s. I believe it is also more Pythonic.
That said, I agree that it is functionally not adding anything new and your concerns are valid re: integer addition, so no stress if you want to just close and I'll work from my fork!
I think the Pythonic argument and the argument that things that can be __add__()
-ed should also be sum()
-able are convincing, and there's no downside here. I'll merge it. Thanks!
These changes allow for the use of
sum()
onOpenSCADObject
lists__radd__
__add__
int
s toOpenSCADObject
sValueError
s if not0
OpenSCADObject
and0
just returns the OpenSCADObject