Konrad Hinsen wrote:
Backwards compatible with what? Currently builtin modules can't be in packages at all, so nothing's lost.
But DLLs *can* be (that's the whole point, no?). If the rules for the init func changes, I think at least Marc-Andre L. won't be too happy: all (?) of his extensions use DLLs as submodules, so he would need to add switches to remain compatible with 1.5.2. I'm sure he's not the only one.
Yep, all my extensions are wrapped into packages and all of them use subpackages which wrap extension modules included as submodules of those packages... that gives you a very flexible setup since the __init__.py files let you do all kinds of nifty things to load the correct C extension (see my previous post).
I admit I hadn't thought about the possibility that someone might have used dynamic libraries in packages already; my development cycles always include statically linked modules at some stage, so all extension modules remain top-level.
The main reason for including the extensions in the packages themselves rather than making them top-level was to simplify installation, e.g. on Windows (with pre-compiled binaries), you only have to unzip the archive and that's it... no make install or equivalent is necessary.
Which makes me wonder how others develop extension modules: I always use a debugger at some point, and I haven't yet found one which lets me set breakpoints in dynamic libraries that haven't been loaded yet!
That one is simple: you run it twice. The first time to load the DLL and the second time with the break point set in the DLL. Works with gdb on Linux, not sure about other platforms.