Publish `plum-dispatch-purepython` without C extensions to PyPI

If my benchmarks are accurate (using benchmark.py), cythonising plum.function is at best 2x faster. For our use-case — a high-level framework on top of lower-level libraries like numpy and torch — this isn’t worth the loss of stack trace and inspect support.

@wesselb would you consider publishing a build of plum without C extensions to PyPI?

One way to go about this is for setup.py to only add to ext_modules if an environment variable is set (e.g. USE_CYTHON), and for the GitHub Action to do an additional build and publish with that variable set. If you’re on board, I’m happy to help where I can!

[wesselb]

Hey @seeM!

Sorry for not replying sooner. I’ve been in the last stretch of writing up my dissertation, which is now finally done, so I can get back to it.

If Cythonising plum.function only gives a 2x speed-up, perhaps the right choice is to get of Cythonising entirely in the main library. As you say, perhaps the loss of stack trace and inspection support isn’t worth it. @PhilipVinc, what are your thoughts on this?

I am taking a break until the end of next week, during which I won’t have access to my laptop. After that, I’ll be back to work. Once I’m back, I’ll setup a few more careful benchmarks to really figure out the benefits of Cythonising. If the benefits are only marginal and if others agree, perhaps we can then decide to just get rid of the compilation step wholly.

[jmosbacher]

Just came to the issues section to ask this very question. This would be greatly appreciated! I absolutely love this package and want to use it for everything but I also really want my packages to be usable in pyscript so I feel like my parents are going through a rough divorce and forcing me to choose… PS @wesselb congrats on finishing your thesis! this package is truly awesome.