cython(): do not include .pxi files

[jdemeyer]

The function cython() currently adds a header to every .pyx file:

include "cdefs.pxi"
include "cysignals/signals.pxi"  # ctrl-c interrupt block support
include "stdsage.pxi"

If we want cython() to become less Sage-specific (see for example #22461), we should stop doing this. The user can still manually add the includes.

Moreover, Cython is trying to phase out .pxi files in general, which is an additional reason to get of those headers.

Note that I don't see an easy way to make this backwards-compatible. The only thing that we can do is to give a good error message (which is what this patch does). Because it's a backwards-incompatible change, it should preferably be done in a major version bump (i.e. Sage 8.0). Therefore I am making this a blocker.

[jdemeyer]

New commits:

​0a622e6

cython(): do not include .pxi files

[tscrim]

There isn't a way to add the corresponding cimport statements to the code before sending it off to Cython? I'm not against this change, but I don't see why we can't have the same functionality available from Sage (mostly out of ignorance).

[jdemeyer]

Replying to tscrim:

There isn't a way to add the corresponding cimport statements to the code before sending it off to Cython?

Yes, of course there is. We could just add cimport statements instead of include statements.

But my point is that it shouldn't be the business of Sage to add that. This is especially true in the light of #22461. I think that the user can easily add those cimports himself.

[tscrim]

Why shouldn't we have Sage do a little bit extra on top of standard Cython to make things easier for our users? Even with this change, I don't think we could completely separate cython() from standard Cython because we give the users access to our standard Sage classes. I guess I don't see the point of making things harder for (more basic) users.

[jdemeyer]

Replying to tscrim:

we give the users access to our standard Sage classes.

First of all, the relevant .pxi files have almost nothing to do with Sage: they add support for cysignals (i.e. the sig_check/sig_on stuff and memory functions like sig_malloc), some arbitrary set of C functions like memset and fopen and all GMP functions like mpz_init. So there is really nothing Sage-specific about this.

Second, even if you argue that cython() should add those things, it should still be possible to just use plain Cython without any extra cimports. This could be implemented with an additional option to cython(). I already thought about this when starting this ticket, but then thought that Sage changing Cython files is just a misfeature.

[tscrim]

Okay, then I'm willing to set this to a positive review. I doubt it was a much used (mis)feature, but we will see in the beta stages I think.

[vbraun]

See the patchbot errors, breaks spyx compilation

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f2bcabd	Upgrade to cysignals version 1.6.3
​8c05957	Fix doctest for cysignals upgrade
​9745f93	cython(): do not include .pxi files
​9c66c20	Fix .spyx doctest