Our crack team of Pythonistas is contemplating which of several Python OCCT bindings to require in an unrelated third-party project. Rejoice, for OCP is one of those! We couldn't help but notice the phenomenal job the CadQuery community has done here. Big kudos to all involved. 👍
So, let's hear it for our finalists:
Of the three, OCP superficially seems to be the most bleeding-edge, the most stable, and the least documented – and at least one of those things is good. The underlying clang-based pywrap binding generator leveraged by OCP looks to be well ahead of both:
From prior work, I'm intimately familiar with the similar clang-based Shiboken2 binding generator leveraged by PySide2. Since Shiboken2 worked perfectly, I'm a bit leery of binding generators that "go their own way" rather than reuse standard off-the-shelf C[++] parsers like clang. But what do I know? I'm just the disreputable backend guy.
Given how fresh and shiny OCP is, would you advise third-party Python packages to begin requiring OCP as a mandatory runtime dependency... or would that be a premature act of job suicide? I suspect the latter but am hoping for the former.
In any case, thanks for all the tremendous outpouring of CadQuery volunteerism. Whether we decide to ditch OCP for something substantially worse or not, this is an incredibly inspiring effort. Let's all change the CAD industry for the better.
Our crack team of Pythonistas is contemplating which of several Python OCCT bindings to require in an unrelated third-party project. Rejoice, for OCP is one of those! We couldn't help but notice the phenomenal job the CadQuery community has done here. Big kudos to all involved. 👍
So, let's hear it for our finalists:
Of the three, OCP superficially seems to be the most bleeding-edge, the most stable, and the least documented – and at least one of those things is good. The underlying clang-based
pywrapbinding generator leveraged by OCP looks to be well ahead of both:pybind11binding generator internally leveraged bypyOCCT. Whereaspywrapjust defers to clang,pybind11implements its own ad-hoc C[++] header macro system requiring changes to source code. That makes my hackles rise.pythonocc-core. SWIG is likepybind11on performance-enhancing supplements. Everyone wishes SWIG would just use clang instead, but that's unlikely to happen within the known lifetime of our Universe.From prior work, I'm intimately familiar with the similar clang-based Shiboken2 binding generator leveraged by PySide2. Since Shiboken2 worked perfectly, I'm a bit leery of binding generators that "go their own way" rather than reuse standard off-the-shelf C[++] parsers like clang. But what do I know? I'm just the disreputable backend guy.
Given how fresh and shiny OCP is, would you advise third-party Python packages to begin requiring OCP as a mandatory runtime dependency... or would that be a premature act of job suicide? I suspect the latter but am hoping for the former.
In any case, thanks for all the tremendous outpouring of CadQuery volunteerism. Whether we decide to ditch OCP for something substantially worse or not, this is an incredibly inspiring effort. Let's all change the CAD industry for the better.