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).
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).
https://github.com/jpmlt/freecad-cadquery2-workbench
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:
https://build123d.readthedocs.io/en/latest/key_concepts.html...
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).