Allow cimport for quicktions

[nocarryr]

Share the quicktions.Fraction extension type definitions with other Cython modules.

To make distribution possible from a pip install, the sources have to be included in the built wheels. The project layout prevents this (AFAIK) since only the compiled binaries would be included.

Placing quicktions into a sub-directory as a proper package (with __init__.py) seemed the best solution:

* src
  * quicktions
    * __init__.py
    * quicktions.pyx
    * quicktions.pxd

I realize this may be an undesirable change and can understand if it's not a direction you would like to go with this project.

[nocarryr]

Thanks! I think it's worth avoiding a package, though. Why not add quicktions.pxd to the package_data with package_data={'': ['quicktions.pxd']}) ? Could you maybe send a new (cleaned up) pull request for that, which avoids all the moving around of files?

That was my initial endeavor, but I could never get the packaged wheel to include anything other than the compiled binary. This is expected due to the project not containing any valid packages. ("src layout", but no packages within "src/") https://setuptools.readthedocs.io/en/latest/setuptools.html#using-a-src-layout

My prior (unsuccessful) attempts were here: https://github.com/nocarryr/quicktions/tree/pxd-header

[cjdsellers]

Greetings,

I was wondering where we might be at with facilitating cimporting Fraction from quicktions?

[scoder]

@cjdsellers difficult to say. To me, it feels like this PR is trying to do way too many things, but @nocarryr apparently got there by trying simpler things first, so I don't know. If there is a simple way to allow from quicktions cimport Fraction, then I'd be happy to get that included.

[nocarryr]

@scoder I agree

Without changing the project's layout, it's not possible AFAIK to include and package the .pxd file so things are importable from pure Python and on Cython's search path.

I think I realized the simplicity of quicktions's layout (matching the Python stdlib as closely as possible) was more valuable than the (likely insignificant) performance increase of making it cimportable.

It would seem more beneficial to create that functionality as a completely separate project (which I've started working on here and there). That way it can be designed with much less GIL interaction required.

Should I just close this PR?

[cjdsellers]

Ok, I thought it might have been a simple fix with just writing a .pxd. However I understand there are other complexities here around the packaging, and I understand that one of the main values of the library is a drop in replacement for Fraction.

I'm looking for a high performance decimal type object which I can inherit from for C extension modules compiled with Cython. It would provide the base for some value type domain objects for a trading platform I've been developing. All production code has been written with Cython.

https://github.com/nautechsystems/nautilus_trader

I appreciate your response and look forward to anything you may come up with regarding the above.

[nocarryr]

@scoder do you think cython/cython#2910 would be a viable alternative to this approach?

[scoder]

do you think cython/cython#2910 would be a viable alternative to this approach?

That does not seem related. If quicktions ships a .pxd file, it will be picked up. Cython's own .pxd files are not relevant here.

[scoder]

I appreciate your response and look forward to anything you may come up with regarding the above.

Well, you can always define your own quicktions.pxd and use it. Cython does not care where the file came from, as long as it finds it somewhere on the Python import path.

[cjdsellers]

Well, you can always define your own quicktions.pxd and use it. Cython does not care where the file came from, as long as it finds it somewhere on the Python import path.

I'll try that approach, thank you!