[PyQt] Order of %Import vs. %Include directives affects generated output with respect to namespaces?

Phil Thompson phil at riverbankcomputing.com
Sat Nov 20 15:04:32 GMT 2010


On Tue, 16 Nov 2010 13:57:02 -0800, Nate Reid <gnatty7 at hotmail.com> wrote:
> This is using sip 4.10
> 
> 
> // Example module that produces erroneous output
> 
> %Module example
> 
> 
> %Import mapped_types.sip // A separately compiled module with some
mapped
> types
> 
> 
> %Import some_module.sip // This is before the %Includes
> 
> 
> %Include file.sip // A wrapped class that uses a wrapped class in
> some_module under the 'myns' namespace
> 
> %Include ...
> 
> ...
> 
> 
> 
> If I change the order of the directives to the following:
> 
> // "Correct" example that produces functional  output but  requires
> reording
>  of the Imports
> 
> %Module example
> 
> %Import mapped_types.sip
> 
> %Include file.sip 
> 
> %Include ...
> 
> ...
> 
> %Import some_module.sip // This is now after the %Include(s)
> 
> ...
> 
> 
> 
> The output changes with respect to the namespace definitions in the
> sipClassTypeDef struct defnitions
> 
> The first produces something like this is the
> // sip_examplemyns.cpp
> sipClassTypeDef sipTypeDef__example_myns = {
>     {
>         -1,
>         0,
>         0,
>         SIP_TYPE_NAMESPACE,
>         sipNameNr_myns,
>         {0}
>     },
>     {
>         -1,
>         {2, 0, 0},
>         0, 0,
>         0, 0,
>         0, 0,
>         {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
>     },
>     0,
> 
> 
> While the second one with the reordering of the %Import produces:
> // sip_examplemyns.cpp
> 
> ...
> 
> sipClassTypeDef sipTypeDef__example_myns = {
> 
>     {
> 
>         -1,
> 
>         0,
> 
>         0,
> 
>         SIP_TYPE_NAMESPACE,
> 
>         sipNameNr_myns,
> 
>         {0}
> 
>     },
> 
>     {
> 
>         sipNameNr_myns, // Difference!
> 
>         {0, 0, 1},                // Difference!
> 
>         0, 0,
> 
>         0, 0,
> 
>         0, 0,
> 
>         {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
> 
>     },
> 
> 
> When I load the module in python for the first example above, the
> namespace 'class' isn't there:
> e.g.
>>>> import example
>>>> example.myns # doesn't exist
> 
> Whereas the second version with the %Import some_module after the the
> %Includes gives me
>>>> import example
>>>> examp.myns # exists
> 
> Is this some sort of bug in sip that's been fixed in a newer version of
> SIP?  I tried to create a full example that shows this problem but I was
> hoping that this information is enough to help explain what was going
on.

It is a "bug", but the reverse of what you think...

SIP implements namespaces as a Python class. That class is only
implemented in one module - the first one that defines it. Objects that are
defined in the same C++ namespace, but in other modules, are placed in the
Python class in that original module. In your example you should expect to
find the contents of the myns namespace defined in the example module in
some_module.myns and not in example.myns.

Every time I explain this I get more uncomfortable with this behavior. I
had planned (at some point) to implement a way to tell SIP to generate
example.myns containing the contents of the namespace define in the example
module. However you have stumbled across a way of doing it - so the "bug"
is now a feature.

In tonight's snapshot I've documented the two different behaviors. I've
also changed the parser to allow...

namespace myns;

...as a convenient way of defining a namespace with no initial contents.

Phil


More information about the PyQt mailing list