Philipp, On 3 November 2017 at 12:52, Philipp A. <flying-sh...@web.de> wrote: > Hi Shaheed, > > Thank you so much for all your work! > >> a framework-by-framework integration of the binding generation logic (as >> previously pioneered by Steve) probably cannot work in general because there >> are cases where multiple frameworks contribute to to the same C++ namespace >> […] >> >> The problem is that the Python implementation of these namespaces is a >> class, and so treating these frameworks […] as separate would result in >> multiple colliding Python class definitions. > > > Am I missing something? Namespaces should be Python modules, not classes. If > we can do represent them this way, the problem is solveable: > https://packaging.python.org/guides/packaging-namespace-packages/
First, I am using this technique at the KF5 level (the pkg-util version). My concerns about using it to address the namespace problem are that: - my overall understanding of this technique is that it may end up being fragile, especially given the difference between P2 and P3. - using it further down might not work as expected especially if there are "accidental" collisions in the directory/namespace names. - it is also not clear if the technique can be used multiple times. - cppyy gives us classes. (Actually, in conversation with Wim, CC'd here, it turns out that the choice of using classes is not arbitrary, but we were pondering simple modules at that point, for other reasons). Bottom line: I'm not keen on using Python namespace modules here for the reasons listed. >> The original TODOs and bugs have been resolved, and there is the >> beginnings of support for packaging frameworks under a Python namespace as >> in "KF5.KDCRAW". > > > Once they’re modules, we should probably respect that Python modules are by > convention lowercase. It would be best if we named them kf5.kdcraw and so > on. That's likey to be a bad idea because of the potential impact on arbitrary round trips between C++ and Python (remember that everything is based on named-based lookups). In addition, we already have problems like "gpgme++", and the use of capitalisation to separate legacy and forwarding headers in KDE: further case-based confusion is the last thing that is needed! Thanks for the review/remarks, Shaheed > Thank you again, > Best, Philipp