Repository navigation
MAINT: Remove Python <3.8 support from C - #20315
Conversation
|
Apparently LGTM is using Python 3.7. |
They were supposed to fix that last quarter, we will have to disable LGTM if they don't. Supposedly there is a more current replacement (code scanning alerts) in the security tab we can use as a replacement. |
|
For reference, here's the mailing list thread from August: Drop LGTM testing. More discussion of LGTM occurred in this PR: #19665 |
|
Let's just drop LGTM. We can restore it later if LGTM updates their python. Does it make sense to do that here, or would it be cleaner to do it in a separate PR? |
We can disable the access or remove it in |
|
I suspended the app. Let's restart and see what happens. |
|
I've added the github code scanner, it should be using Python 3.8 (Ubuntu 20-04). If not we can remove it again :) |
|
Looks like CodeQL does a shallow checkout of the numpy git repository, and that causes a problem in the "CodeQL / Analyze (cpp)" check. Its attempt to build numpy fails because versioneer needs the latest git tag to create the numpy version. |
That's not the only problem. I let it make the automatic commit, which was a mistake. I'm going to remove it and leave it for another day as it is going to take some effort to get it working and that is better done as a PR. |
Remove version switches for support of Python versions before 3.8. The biggest deletion is that we can use Pythons `PyVectorcall_Call` to support the old `*args, **kwargs` style call convention in ufuncs.
4281408 to
abca5ca
Compare
|
@seberg Could you also update the Python version check in setup.py? |
Previously, this was not strictly enforced for the only purpose of running LGTM (hoping it would be fixed before the 1.22 release).
|
Thanks Sebastian. We could also update the default pickle protocol to 4, the default in Python 3.8. That would allow large pickles by default. AFAICT, the current default is 2, probably for Python 2.7 compatibility. I'll make the proposition on the mailing list. |
|
Is this a good idea? Doesn't this mean pip is unable to read the |
|
@eric-wieser what you mean that it would break the PyPI listing? https://pypi.org/project/numpy/1.22.0rc1/ does correctly show |
The type `vectorcallfunc` is not defined by Python's limited API. Guard its use with a `#ifdef` so that third-party extensions that use the Numpy C API will build with Py_LIMITED_API defined. This fixes a regression introduced in numpy#20315.
The type `vectorcallfunc` is not defined by Python's limited API. Guard its use with a `#ifdef` so that third-party extensions that use the Numpy C API will build with Py_LIMITED_API defined. This fixes a regression introduced in numpy#20315.
The type `vectorcallfunc` is not defined by Python's limited API. Guard its use with a `#ifdef` so that third-party extensions that use the Numpy C API will build with Py_LIMITED_API defined. This fixes a regression introduced in numpy#20315.
The type `vectorcallfunc` is not defined by Python's limited API. Guard its use with a `#ifdef` so that third-party extensions that use the Numpy C API will build with Py_LIMITED_API defined. This fixes a regression introduced in numpy#20315.
The type `vectorcallfunc` is not defined by Python's limited API. Guard its use with a `#ifdef` so that third-party extensions that use the Numpy C API will build with Py_LIMITED_API defined. This fixes a regression introduced in numpy#20315.
4 participants
Remove version switches for support of Python versions before 3.8.
The biggest deletion is that we can use Pythons
PyVectorcall_Callto support the old
*args, **kwargsstyle call convention in ufuncs.