8000 MAINT: Allow scipy to be compiled in cython3 by matusvalo · Pull Request #18242 · scipy/scipy · GitHub
[go: up one dir, main page]

Skip to content

MAINT: Allow scipy to be compiled in cython3 #18242

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
May 3, 2023
Merged

Conversation

matusvalo
Copy link
Contributor
@matusvalo matusvalo commented Apr 3, 2023

Reference issue

Fixes #17234

What does this implement/fix?

This PR allows Scipy to be compiled by cython3. This version is just PoC and should not be merged. Feel free to close this PR when is not needed anymore.

Requirements

  • Cython master

Additional information

Part of the PR is coming from #18224

This PR has following predecessors/requirements:

@matusvalo
Copy link
Contributor Author
matusvalo commented Apr 3, 2023

Except replacing relative imports with absolute one, the rest of PR is just annotating functions as noexcept. Declaring functions as noexcept can be first step of porting codebase to Cython3. This step is also 100% backward compatible with cython >= 0.29.31.

@tacaswell
Copy link
Contributor

I can confirm that this builds (and I was going completely the wrong direction in trying to debug this!).

Copy link
Member
@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The noexcept changes LGTM. Could you split those off into a separate PR perhaps?

@@ -1 +1 @@
from .linalg cimport cython_blas, cython_lapack
from scipy.linalg cimport cython_blas, cython_lapack
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stated preference in #17234 was to keep this relative, to avoid that this ever picks up some other installed scipy. I understand that this isn't possible (or at least bugfree) with 0.29.x, but wouldn't want to mix these changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me just say that that's not critical - whatever works here to get SciPy to build. We can deal with the rest later.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably still better to have a single commit with the absolute import changes to allow rolling it back independently at some point. Although there will likely be a couple of conflicts by then, but I'd guess that it would still help.

@tirthasheshpatel
Copy link
Member

The build succeeds but I am getting this error on Ubuntu 22.04 with Python 3.11:

image

@rgommers rgommers added the maintenance Items related to regular maintenance tasks label Apr 4, 2023
schuylermartin45 added a commit to AnacondaRecipes/scipy-feedstock that referenced this pull request Apr 4, 2023
- Updates SciPy to v1.10.1
- This fixes a reported bug for a customer
- Removes `setup.py` dependency as per the linter's suggestion
  - Doing so caused a handful of new dependencies, as we were previously
    relying on PyPi to fill in some gaps
- Moves `meson-python` dependency to host section
- Addresses build failure found in upstream [Issue #17234](scipy/scipy#17234)
- Patch file found here:
    - scipy/scipy#18242
    - https://patch-diff.githubusercontent.com/raw/scipy/scipy/pull/18242.patch
schuylermartin45 added a commit to AnacondaRecipes/scipy-feedstock that referenced this pull request Apr 4, 2023
- Updates SciPy to v1.10.1
- This fixes a reported bug for a customer

Eric, Ari, and I attempted to move away from using `setup.py` but as Marco
stated in the last version bump, `mesonpy` doesn't have great support for
non-Linux platforms. Ari recently added some in-house support for other
platforms, but we're still at a loss. Here are some notes on what we
attempted/how far we got:

- Swapped the `setup.py` line in `build.sh` for:
  `$PYTHON setup.py install --single-version-externally-managed --record=record.txt`
- Added `- meson-python 0.12.1` to the `host` section of `meta.yaml`
- Found a build failure known to upstream [Issue #17234](scipy/scipy#17234)
    - Attempted to patch the build with the file found here:
        - scipy/scipy#18242
        - https://patch-diff.githubusercontent.com/raw/scipy/scipy/pull/18242.patch

At the end of all this, the build fails on trying to build a Windows
executable:
```
Sanity testing C compiler: $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc
Is cross compiler: False.
Sanity check compiler command line: $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc sanitycheckc.c -o sanitycheckc.exe -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/scipy-1.10.1 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem $PREFIX/include -D_FILE_OFFSET_BITS=64 -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,$PREFIX/lib -Wl,-rpath-link,$PREFIX/lib -L$PREFIX/lib -shared
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----
Running test binary command:  $SRC_DIR/builddir/meson-private/sanitycheckc.exe

meson.build:1:0: ERROR: Executables created by c compiler $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc are not runnable.
```

So given the urgency of the customer request, we decided to revert our work
and ignore the linter, sticking with the `setup.py` solution.
schuylermartin45 added a commit to AnacondaRecipes/scipy-feedstock that referenced this pull request Apr 4, 2023
- Updates SciPy to v1.10.1
- This fixes a reported bug for a customer
- Adds linter skipping for known issues (see below)

Eric, Ari, and I attempted to move away from using `setup.py` but as Marco
stated in the last version bump, `mesonpy` doesn't have great support for
non-Linux platforms. Ari recently added some in-house support for other
platforms, but we're still at a loss. Here are some notes on what we
attempted/how far we got:

- Swapped the `setup.py` line in `build.sh` for:
  `$PYTHON setup.py 
8000
install --single-version-externally-managed --record=record.txt`
- Added `- meson-python 0.12.1` to the `host` section of `meta.yaml`
- Found a build failure known to upstream [Issue #17234](scipy/scipy#17234)
    - Attempted to patch the build with the file found here:
        - scipy/scipy#18242
        - https://patch-diff.githubusercontent.com/raw/scipy/scipy/pull/18242.patch

At the end of all this, the build fails on trying to build a Windows
executable:
```
Sanity testing C compiler: $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc
Is cross compiler: False.
Sanity check compiler command line: $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc sanitycheckc.c -o sanitycheckc.exe -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/scipy-1.10.1 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem $PREFIX/include -D_FILE_OFFSET_BITS=64 -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,$PREFIX/lib -Wl,-rpath-link,$PREFIX/lib -L$PREFIX/lib -shared
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----
Running test binary command:  $SRC_DIR/builddir/meson-private/sanitycheckc.exe

meson.build:1:0: ERROR: Executables created by c compiler $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-cc are not runnable.
```

So given the urgency of the customer request, we decided to revert our work
and ignore the linter, sticking with the `setup.py` solution.
@matusvalo
Copy link
Contributor Author

The build succeeds but I am getting this error on Ubuntu 22.04 with Python 3.11:

image

I will try to have a look on that.

@tacaswell
Copy link
Contributor

with cpython master + cython master (3.0.0b2-36-g781b087c9) + this branch I'm now getting failures that look like:

FAILED: scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o 
ccache c++ -Iscipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p -Iscipy/special -I../../scipy/special -I../../scipy/_lib/boost_math/include -Iscipy/_lib -I../../scipy/_lib -I../../scipy/_build_utils/src -I../../../../../home/tcaswell/.virtualenvs/bleeding/lib/python3.12/site-packages/numpy/core/include -I/home/tcaswell/.pybuild/bleeding/include/python3.12 -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -O2 -fpermissive -fPIC -Wno-cpp -DBOOST_MATH_STANDALONE=1 -MD -MQ scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o -MF scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o.d -o scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o -c scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp: In function ‘long int __Pyx_PyInt_As_long(PyObject*)’:
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:1212:13: warning: suggest parentheses around ‘-’ in operand of ‘&’ [-Wparentheses]
 1212 |         ((1 - ((PyLongObject*)x)->long_value.lv_tag & 3) * (((PyLongObject*)x)->long_value.lv_tag >> 3))  // (>> NON_SIZE_BITS)
      |           ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6384:25: note: in expansion of macro ‘__Pyx_PyLong_SignedDigitCount’
 6384 |                 switch (__Pyx_PyLong_SignedDigitCount(x)) {
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6385:27: error: narrowing conversion of ‘-2’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6385 |                     case -2:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6403:27: error: narrowing conversion of ‘-3’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6403 |                     case -3:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6421:27: error: narrowing conversion of ‘-4’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6421 |                     case -4:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp: In function ‘int __Pyx_PyInt_As_int(PyObject*)’:
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:1212:13: warning: suggest parentheses around ‘-’ in operand of ‘&’ [-Wparentheses]
 1212 |         ((1 - ((PyLongObject*)x)->long_value.lv_tag & 3) * (((PyLongObject*)x)->long_value.lv_tag >> 3))  // (>> NON_SIZE_BITS)
      |           ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6587:25: note: in expansion of macro ‘__Pyx_PyLong_SignedDigitCount’
 6587 |                 switch (__Pyx_PyLong_SignedDigitCount(x)) {
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6588:27: error: narrowing conversion of ‘-2’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6588 |                     case -2:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6606:27: error: narrowing conversion of ‘-3’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6606 |                     case -3:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:6624:27: error: narrowing conversion of ‘-4’ from ‘int’ to ‘long unsigned int’ [-Wnarrowing]
 6624 |                     case -4:
      |                           ^
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp: In function ‘Py_ssize_t __Pyx_PyIndex_AsSsize_t(PyObject*)’:
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:1212:13: warning: suggest parentheses around ‘-’ in operand of ‘&’ [-Wparentheses]
 1212 |         ((1 - ((PyLongObject*)x)->long_value.lv_tag & 3) * (((PyLongObject*)x)->long_value.lv_tag >> 3))  // (>> NON_SIZE_BITS)
      |           ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:7143:31: note: in expansion of macro ‘__Pyx_PyLong_SignedDigitCount’
 7143 |       const Py_ssize_t size = __Pyx_PyLong_SignedDigitCount(b);
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@tacaswell
Copy link
Contributor

cython/cython#5361 fixes the above build error.

@rgommers rgommers added this to the 1.11.0 milestone Apr 6, 2023
@rgommers
Copy link
Member
rgommers commented Apr 6, 2023

Thanks for working on this! If there's parts that can be merged separately so the rest is easier to work on, we can do that.

@tirthasheshpatel
Copy link
Member
tirthasheshpatel commented Apr 7, 2023

I will try to have a look on that.

@matusvalo After looking into this a bit, I found the offending code to be introduced in cython/cython#5040. This seems to be a bug fix for C++ public functions but SciPy didn't fail before since the function was a C function and it erroneously got declared as one in the generated C++ file (up until Cython 3.0.0). Which is why the symbol was found and everything just worked. Now that extern "C++" gets added to public functions, it can't find the symbol and it errors out.

Does Cython allow overriding this behavior i.e. explicitly declaring a Cython function as an extern "C" so that it gets that scope added in the generated C++ file when compiling in C++ mode?

@tirthasheshpatel
Copy link
Member

Found this comment. Just need to change this line:

cpp_args: [cython_cpp_args, '-DBOOST_MATH_STANDALONE=1'],

to:

  cpp_args: [cython_cpp_args, '-DBOOST_MATH_STANDALONE=1', '-D__PYX_EXTERN_C=extern "C"'],

@matusvalo
Copy link
Contributor Author

Found cython/cython#5040 (comment). Just need to change this line:

Added to this PR

@matusvalo
Copy link
Contributor Author

We need to change __PYX_EXTERN_C to CYTHON_EXTERN_C after merging cython/cython#5371 .

@matusvalo
Copy link
Contributor Author

We need to change __PYX_EXTERN_C to CYTHON_EXTERN_C after merging cython/cython#5371 .

CYTHON_EXTERN_C will be introduced in Cython 3.0b3 release

@matusvalo
Copy link
Contributor Author

When running test suite, it freezes on following test: scipy/stats/tests/test_qmc.py::TestUtils::test_discrepancy_parallel. To be honest, cannot tell why.

@matusvalo
Copy link
Contributor Author
matusvalo commented Apr 21, 2023

BTW. Now it seems that test suite fails only with following two tests:

FAILED scipy/linalg/tests/test_cythonized_array_utils.py::test_bandwidth_dtypes - ValueError: cannot include dtype 'M' in a buffer
FAILED scipy/linalg/tests/test_cythonized_array_utils.py::test_issymetric_ishermitian_dtypes - ValueError: cannot include dtype 'M' in a buffer

@matusvalo
Copy link
Contributor Author

BTW. Now it seems that test suite fails only with following two tests:

FAILED scipy/linalg/tests/test_cythonized_array_utils.py::test_bandwidth_dtypes - ValueError: cannot include dtype 'M' in a buffer
FAILED scipy/linalg/tests/test_cythonized_array_utils.py::test_issymetric_ishermitian_dtypes - ValueError: cannot include dtype 'M' in a buffer

OK I can replicate the issue with following simple example:

cimport numpy as cnp
import cython

ctypedef fused np_numeric_t:
    cnp.int8_t
    cnp.int16_t
    cnp.int32_t
    cnp.int64_t
    cnp.uint8_t
    cnp.uint16_t
    cnp.uint32_t
    cnp.uint64_t
    cnp.float32_t
    cnp.float64_t
    cnp.longdouble_t
    cnp.complex64_t
    cnp.complex128_t

@cython.initializedcheck(False)
def bandwidth_c(np_numeric_t[:, ::1]A):
    return

When compiled following code with cython 0.29.X:

>>> import numpy as np
>>> zz = np.zeros([5, 5], dtype='M')
>>> import fused
>>> fused.bandwidth_c(zz)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "fused.pyx", line 32, in fused.__pyx_fused_cpdef
    def bandwidth_c(np_numeric_t[:, ::1]A):
TypeError: No matching signature found

When compiled following code with Cython 3:

>>> import numpy as np
>>> zz = np.zeros([5, 5], dtype='M')
>>> import fused
>>> fused.bandwidth_c(zz)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "fused.pyx", line 31, in fused.__pyx_fused_cpdef
    @cython.initializedcheck(False)
ValueError: cannot include dtype 'M' in a buffer

@matusvalo
Copy link
Contributor Author

I have raised a question about the issue in the Cython devel mailing list: https://mail.python.org/pipermail/cython-devel/2023-April/005422.html

@rgommers
Copy link
Member

Thanks @matusvalo. I think it's fine to change these tests to (perhaps temporarily) accept also ValueError. They're not very important tests, so if it could get CI green so we can merge this PR, that'd be justifiable. We can add a follow up issue then to keep track of this and either accept and document the minor regression if Cython's behavior change stays like that, or revert the test patch otherwise.

@da-woods
Copy link
Contributor

I have raised a question about the issue in the Cython devel mailing list: https://mail.python.org/pipermail/cython-devel/2023-April/005422.html

Just repeating what I posted on the mailing list:

I made a change to optimize dispatch of fused memoryview types. I suspect that's inadvertently caused the change. I have a reasonable idea what needs to be fixed, but would need to investigate properly.

I don't think it's an intended change.

(I think the fix would need to go here cython/cython@805d7f3#r110191078, but I haven't yet investigated properly)

@matusvalo
Copy link
Contributor Author

Thank you @da-woods. In order to track here the issue I have created issue in Cython - cython/cython#5401

@matusvalo
Copy link
Contributor Author

if it could get CI green so we can merge this PR

@rgommers I am not 100% sure whether we can merge this PR. This PR still requires unmerged branch in Cython in order to work properly cython/cython#5386. If someone from Cython core devs can accept it and merge it, then I think we can proceed putting this PR to master.

@rgommers rgommers changed the title Maint: Allow scipy to be compiled in cython3 MAINT: Allow scipy to be compiled in cython3 Apr 25, 2023
@tacaswell
Copy link
Contributor

I'm now seeing

[347/1624] Compiling C++ object scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o
FAILED: scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o
ccache c++ -Iscipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p -Iscipy/special -I../../scipy/special -I../../scipy/_lib/boost_math/include -Iscipy/_lib -I../../scipy/_lib -I../../scipy/_build_utils/src -I../../../../../home/tcaswell/.virtualenvs/bleeding/lib/python3.12/site-packages/numpy/core/include -I/home/tcaswell/.pybuild/bleeding/include/python3.12 -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -O3 -fpermissive -fPIC -Wno-cpp -DBOOST_MATH_STANDALONE=1 '-DCYTHON_EXTERN_C=extern "C"' -MD -MQ scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o -MF scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o.d -o scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o -c scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp
In file included from /home/tcaswell/.pybuild/bleeding/include/python3.12/internal/pycore_frame.h:9,
                 from scipy/special/_ufuncs_cxx.cpython-312-x86_64-linux-gnu.so.p/_ufuncs_cxx.cpp:5775:
/home/tcaswell/.pybuild/bleeding/include/python3.12/internal/pycore_code.h:229:76: error: expected ‘,’ or ‘...’ before ‘class’
  229 | extern void _Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *class, PyObject *self,
      |                                                                            ^~~~~

Which I think is related to python/cpython#103809 but I think this is something that needs to be fixed upstream because they used a c++ keyword as a variable name which then fails when included into a c++ file.

@matusvalo
Copy link
Contributor Author

that needs to be fixed upstream because they used a c++ keyword as a variable name which then fails when included into a c++ file

This header is internal and should not be used hence I think they can be reluctant changing it. I will create issue in Cython first,

@scoder
10000 Copy link
scoder commented Apr 28, 2023 via email

@matusvalo
Copy link
Contributor Author

@rgommers all dependencies were merged to master in Cython. Now scipy can be build with Cython master and the test suite passes. I am marking this PR as ready for review.

@matusvalo matusvalo marked this pull request as ready for review May 3, 2023 13:09
Copy link
Member
@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice work getting this to pass @matusvalo!

This looks good to go. Let me just add one instance of each of the build warnings that are visible in the CI log for completeness:

The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.

The 'DEF' statement is deprecated and will be removed in a future Cython version. Consider using global variables, constants, and in-place literals instead. See https://github.com/cython/cython/issues/4310

Each of the above appears many times, and isn't fixable or best ignored right now.

And then there's one of this, which I think is fixable but that's not critical so we can leave it alone too:

Only extern functions can throw C++ exceptions.

Just to be sure, does that all sound right?

@matusvalo
Copy link
Contributor Author

The 'DEF' statement is deprecated and will be removed in a future Cython version. Consider using global variables, constants, and in-place literals instead. See cython/cython#4310

DEF is deprecated starting with Cython 3.0. There is currently no direct substitute (except declaring variable as standard global variable). In any case there is no near-term plan removing it so I think it can be left as is right now.

The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.

This can be easily fixed. I think I have somewhere branch with the fix. I can fix it in separate PR.

Only extern functions can throw C++ exceptions.

This I don't know to be honest. I know only basics from C++ unfortunately.

@matusvalo
Copy link
Contributor Author

I can fix it in separate PR.

PR created: #18418

@rgommers
Copy link
Member
rgommers commented May 3, 2023

Thanks, that all sounds good. In it goes!

@rgommers rgommers merged commit a181fd5 into scipy:main May 3, 2023
@matusvalo matusvalo deleted the cython3 branch May 3, 2023 20:26
h-vetinari added a commit to h-vetinari/scipy that referenced this pull request Jun 30, 2023
Partially revert "MAINT: Allow scipy to be compiled in cython3 (scipy#18242)"

See commit a181fd5.
h-vetinari added a commit to h-vetinari/scipy that referenced this pull request Aug 29, 2023
* Partially revert "MAINT: Allow scipy to be compiled in cython3 (scipy#18242)"

  See commit a181fd5.

* Revert "BLD: copy `cython_optimize.pxd` to build dir (scipy#18810)"

  This reverts commit 3c89445.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Items related to regular maintenance tasks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: cythonization / compliation failure with development branch of cython
8 participants
0