> We've set up a package structure that puts all our Cython source in
> one place, but then installs the actual built extensions somewhere
> else -- it seems cleaner that way to us.

> However, we now have a problem:

> when we cimport something, Cython needs the *.pyd file at compile
> time, but then it also puts a run-tiem import inot teh code
> (presumable to import the module compiled from the corresponding *.pyx
> file).

> But in our case, the import path is different at run time and compile
> time, i.e.:

> cythonizing time:

> cimport the_module

> run time

> from package_name.sub_package import the_module

> I thought relative imports might help, but apparently not. All the
> compiled modules are in the same place, so a .the_module relative
> import could theoretically work.

> Is there a solution to this, or should we simply follow what is
> presumably the convention and build/install our compiled modules in
> the same place?

> Fair enough.

>> (Personally, I actually find it cleaner that way, but then again lots
>> of my code is a mixture of Python and Cython files that call each
>> other so putting stuff in a separate place just because it's compiled
>> would be a pain.)

> Similar for us, though it ends up with a LOT of files all in one
> place, so this seemed cleaner. But it's not working, so it's hard to
> call that clean!

> Perhaps that suggests re-organize the packaging of your modules rather
> than dividing things into cython/non-cython (which is at most a
> two-fold reduction in the number of files).

>> Perhaps that suggests re-organize the packaging of your modules rather
>> than dividing things into cython/non-cython (which is at most a
>> two-fold reduction in the number of files).

> Yes, we may want to sub-divide the package more, that does make sense.

>> I could be
>> miss-understanding your layout completely though (and things may be
>> different if you have a whole bunch of supporting raw c files),

> well, yes, but we've got those somewhere else anyway.

>> but
>> the typical setup is that .pyx files in your project are just like .py
>> files except that they happen to be compiled.

> True -- it probably is beter to think of it that way. We do end up with:

> *.py
> *.pxi
> *.pxd
> *.pxy
> *.so (at least in develop or in-place mode)

> for each module -- but not so bad, really.

>> *.py
>> *.pxi
>> *.pxd
>> *.pxy
>> *.so (at least in develop or in-place mode)

>> for each module -- but not so bad, really.

> I am curious why you need a .py and .pxi for each module, on top of
> the .pxy. Historical artifact?

>>> *.py
>>> *.pxi
>>> *.pxd
>>> *.pxy
>>> *.so (at least in develop or in-place mode)

>>> for each module -- but not so bad, really.

>> I am curious why you need a .py and .pxi for each module, on top of
>> the .pxy. Historical artifact?

> This is mostly wrapping some C++ code:

> The .py is there because I prefer to put the pure-python parts of our
> wrappers in pure python -- it makes for easier debugging, etc. I
> suppose once they are mature we could merge it, but I think I like it
> this way.

> the .pxd is for declarations so that we can use the stuff we defined
> in other pyx files.

> But I'm still confused about pxi vs pxd -- maybe we could put it all
> in .pxd files?

> ANd this indicates that we could do away with the extra declarations
> in the pxd files (for our cdef classes). IN fact, that's a bit ugly
> now, putting some info pxd and some in pxy -- so I"ll look into that.

> Yep, it can likely all go into your pxd files.

>> ANd this indicates that we could do away with the extra declarations
>> in the pxd files (for our cdef classes). IN fact, that's a bit ugly
>> now, putting some info pxd and some in pxy -- so I"ll look into that.

> That's still somewhat of an experimental feature, and there are pros
> and cons of having separate declaration files, but sometimes it's nice
> to not have to split things up.

> Sure. Don't drink, but I'm sure we could find a reasonable substitute :).

> Yeah, understandable. A good writeup would be helpful to a lot of
> folks I think. IIRC, you've been using Cython/Pyrex long enough that
> what makes sense may have shifted since you started too...

>>>> (https://github.com/cython/cython/blob/master/Cython/Compiler/Options....
>>>> might be of interest as well.)

> OK -- that shows the option:

> # Allows cimporting from a pyx file without a pxd file.
> cimport_from_pyx = False

> Which looks like a great idea. However:

> 1) how do you change that option -- treating it like compiler
> directive, either with:

> #cython: cimport_from_pyx=False

> or passing it in on the comamnd line:

> cython --cplus  -X cimport_from_pyx=True  multi_rectangle.pyx

> did not work.

> So I changed it in the Options.py file directly. But I'd rather not
> make that a global change!

> After that, Cython now gets psat the cipmport statement, no longer
> with the error tha the *.pxd can not be found. But it doesn't seem to
> work either.

> cdef class Rectangle:
>     cdef c_Rectangle *thisptr      # hold a C++ instance which we're wrapping
>     def __cinit__(self, int x0, int y0, int x1, int y1):
>         self.thisptr = new_Rectangle(x0, y0, x1, y1)
> ....
> (and so on)

> Then in multi_rectangle.pyx, I put:

> from rectangle cimport Rectangle
> ...
>     def addRect(self, Rectangle rect):
>         """
>         add a rectangle object -- this will only take a rectangle object
>         """

>         self.rectangles.append(rect)
> ...

> But I get:

>     def addRect(self, Rectangle rect):
>                      ^
> ------------------------------------------------------------

> multi_rectangle.pyx:24:22: 'Rectangle' is not a type identifier

> so something isn't working.

> I've enclosed the whole package if anyone wants to take a look.

> Thanks,
>   -Chris

> --

> Christopher Barker, Ph.D.
> Oceanographer

> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception

> Chris.Bar...@noaa.gov