[Pyrex] C-API implementation in Pyrex 0.9.6

[Greg Ewing]

Stefan Behnel wrote:
> Just run "python setup.py build_ext -i" and it will fail on the cimport.

This is not a pure Pyrex example, because it
doesn't follow the file naming rules.

I changed it to follow the Pyrex naming rules,
and it worked. So there doesn't seem to be
anything wrong with the generated code.

If Cython is getting the module name correctly
by whatever means it uses, it should work too.
You shouldn't have to change __Pyx_ImportModule,
because it should always be getting passed the
fully qualified name of the module being
imported.

It has occurred to me that what you're doing
in Cython to get the module name may not be
sufficient. Not only does Pyrex need to know
the full name of the module it's compiling, it
needs to know the full name of all the modules
that it's cimporting.

The way Pyrex figures this out at the moment is
by using the filenames. If it's compiling a
module inside a package called 'package' and
you cimport something called 'export', it first
looks for a file called 'package.export.pxd'.
If it finds that, it knows you're doing a relative
import of a module called 'package.export'.
So it passes "package.export" to __Pyx_ImportModule
and all is well.

On the other hand, if it finds a file called
simply 'export.pxd', it assumes you're importing
a top-level module called 'export'. It may seem
to compile all right, but it will fail at run time
because there's no such module. I think this is
what's happening to you.

Hacking __Pyx_ImportModule to look for a local
module is *not* the right way to fix this, because
it's only treating one symptom of the problem.
Pyrex still has the wrong model of the module
namespace at compile time, and this can lead to
various other problems. For instance, if you
also cimport 'package.export' somewhere, then
Pyrex thinks there are two separate modules,
'export' and 'package.export'. Any extension
types or C functions defined therein will get
doubled up, and you'll get complaints about things
like class 'export.Foo' and class 'package.export.Foo'
being incompatible types.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+