Wim, Philipp, On 4 November 2017 at 16:45, Philipp A. <flying-sh...@web.de> wrote: > Hi Wim! > >> So now I have a (C++) namespace 'A' that bears no relationship to anything >> to do with the file system or any type of Python packaging: it exists only >> in memory for the duration of the python session. > > > Yeah, cool, so we just use a path hook and are ready to go right? > > https://www.python.org/dev/peps/pep-0302/#specification-part-2-registering-hooks > > Every framework gets its own path hook that handles imports from that > framework. > > Frameworks with shared namespaces will just handle their own specific paths, > right? > >> The renaming does not actually scare me that much from a performance point >> of view: already, C++ has typedefs for classes and aliases for namespaces. >> There is always the problem of "leakage" as mentioned above, where the >> end-user sees both at some point, but internally, aliasing will work fine: >> it's just another reference to the same object. > > > Cool, so this might be possible after all! Certainly not as a top priority > before getting things to work, but still! > >> It is to attach a meta class for a __getattr__, the use of properties, and >> to allow pickling. The module type does not support meta classes. > > > Can't we replace the framework modules’ type with a subclass of both > “module” and “type”?
FWIW, I already tried that (types.ModuleType is itself a perfectly subclassable class!) in the case where the framework had the form <simplename> and that worked fine. I did not pursue this for the case where the framework name if "KF5.<simplename>", i.e. the case where the shared namespace comes into the picture because of these statements on https://packaging.python.org/guides/packaging-namespace-packages/ under the native Python3-only case: - "It is extremely important that every distribution that uses the namespace package omits the __init__.py or uses a pkgutil-style __init__.py. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." and under the Python2/3 compatible pkg-util case: - "The __init__.py file for the namespace package needs to contain only the following: __path__ = __import__('pkgutil').extend_path(__path__, __name__) Every distribution that uses the namespace package must include an identical __init__.py. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in __init__.py will be inaccessible." Now, none of that may be a limiting factor in the plan you seem to be discussing, but it was part of what made me think "here be dragons"... Shaheed > Thank you for explaining, > Best regards, Philipp