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".
Build123D and CadQuery are actually compatible at the library level, I think? Certainly at the editor/viewer level.
In principle I think this means Build123D could even be given a FreeCAD workbench, but then there is no properly-supported CadQuery2 workbench at the moment (there's a fork that works but I don't think it has a real maintainer, and it's entirely possible that recent changes have broken it).
I definitely agree the implicit variable (in fact I don't think there is really an implicit variable, so much as dynamic scope detection, but we can imagine there is one) set up by the with statment is not particularly "Pythonic" but it is documented precisely here:
It's not ideal but it is still clearer than the CadQuery fluent API, which I don't really like, not because I think fluent APIs are bad at all (quite the opposite, actually) but because I don't believe the one in CadQuery makes a particularly good case for its existence (it's more the selector grammar I am unconvinced by).
Have you taken a look at the build123d "algebra API" yet? It is intended to be near zero magic without any of the with blocks from the "builder API". There are algebra and builder API versions of all of the introductory examples on this page https://build123d.readthedocs.io/en/latest/introductory_exam...
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".