Meh. I mean, really both of these are semanticaly equivalent: they're python wrappers around a B-Rep toolkit (the same one, actually). On top of that they add, inevitably, a slightly opinionated API framework[1].
You don't like fluent APIs, which is your right. I think they have a place, and are a good DRY trick for grouping a bunch of things that would normally be "sequential" and making them look "declarative".
On the other hand I don't much like voodoo, and in my very limited experience with build123d it's sort of full of it. The very first "box" example looks like this:
with BuildPart() as ex1:
Box(length, width, thickness)
Why do we need a with expression here? What's the resource being allocated that must be freed? In particular why bother with "with" since the context appears to be implicit. The allocation gets bound to an "
ex1" variable
that is never used! How does Box() know where to put itself? It doesn't say, you just need to know what magic the toolkit is doing.
I mean, is that fatal? No. I'm sure it's reasonably easy to explain. But everyone has tastes, and mine (informed by decades of scars from APIs like this) run hard toward the "make things explicit" side of the theater.
[1] Because if they didn't they wouldn't have much value. There are OpenCascade python bindings already, after all. But they don't match the use case of "write a simple script to emit your object" and are more aimed at "build a CAD tool".
You don't like fluent APIs, which is your right. I think they have a place, and are a good DRY trick for grouping a bunch of things that would normally be "sequential" and making them look "declarative".
On the other hand I don't much like voodoo, and in my very limited experience with build123d it's sort of full of it. The very first "box" example looks like this:
Why do we need a with expression here? What's the resource being allocated that must be freed? In particular why bother with "with" since the context appears to be implicit. The allocation gets bound to an "ex1" variable that is never used! How does Box() know where to put itself? It doesn't say, you just need to know what magic the toolkit is doing.I mean, is that fatal? No. I'm sure it's reasonably easy to explain. But everyone has tastes, and mine (informed by decades of scars from APIs like this) run hard toward the "make things explicit" side of the theater.
[1] Because if they didn't they wouldn't have much value. There are OpenCascade python bindings already, after all. But they don't match the use case of "write a simple script to emit your object" and are more aimed at "build a CAD tool".