@scoder, is the only way we can avoid writing everything twice by eventually dropping Cython < 3.0?

I don't seem to have permission to restart the azure run. @mattip, @charris, do you know who does?

Restarted. You need to be a member of https://dev.azure.com/numpy/numpy. If you have a user name on dev.azure.com I can add you.

hmm, maybe @charris has to do it. I get a message about that user having an invalid email, but it might be confused since @charris is the adiminstrator not me

@jakirkham, @jbrockmendel, is this all you need?

@eric-wieser I get the error "Given email address eric-wieser is invalid". Looks like the full email address you registered with is needed.

@eric-wieser The email address you got in the error message worked, you are now added. Not sure what your permissions mean...

Yeah, looks like I have no permisions, but numpy does now appear in my list of projects

is the only way we can avoid writing everything twice by eventually dropping Cython < 3.0?

Take it as a nudge to drop Cython 0.x support rather sooner than later. :)

You could use includes to merge multiple files into one. Question is whether you want a single source for most (but not all) of the content right now (i.e. maintain three distinct files and lose the file history when merging them back together), or whether you accept the redundancy because you prefer cleanly dropping a single file at some point when you remove Cython 0.x support. Personally, I'd go for the latter, but YMMV.

When Cython3 comes out we can require it and drop the older support pretty quickly. The older one is still shipped with Cython<3, so we shouldn't be breaking anyone's workflow.

@jakirkham, is this all you need?

Sorry I've lost the thread. What is this related to?

@jakirkham, @jbrockmendel, in regards to your original motivation for #16363

@jakirkham, in regards to your original motivation for #16363

Sorry I'm still lost

Put simply: if this gets merged, can your PR be closed in your opinion?

Put simply: if this gets merged, can your PR be closed in your opinion?

Maybe you are meaning to ask @jbrockmendel?

Whoops, I did. Sorry for the confusion.

No worries 🙂 Wasn’t sure if there was a relevant NumPy issue I had forgotten 😅

Put simply: if this gets merged, can your PR be closed in your opinion?

Quite likely. I'd like to check that performance doesn't take a hit as compared with the implementation in my PR.

Could the same magic be used to make datetime64 and timedelta64 available?

Yes, but let's leave that to a follow up

Lets put this in, it has been sitting around for way to long and seems completely unproblematic to me. Thanks!

Could the same magic be used to make datetime64 and timedelta64 available?

Yes, but let's leave that to a follow up

Trying to follow up on this, added

    ctypedef class numpy.datetime64 [object PyObject]:
        pass
    ctypedef class numpy.timedelta64 [object PyObject]:
        pass

along with the declarations in this PR, but at import time I'm getting

RuntimeWarning: numpy.datetime64 size changed, may indicate binary incompatibility. Expected 16 from C header, got 32 from PyObject

which is enough to stop the tests from running. Did you have something else in mind for how the followup would work?

Is numpy.datetime64 currently exposed as the full struct? You can add an ignore flag like for ndarray I guess, although I am surprised it is necessary, and I am curious whether this is just a matter of recompiling? (assuming this is within NumPy itself, if it is outside you should not have to recompile of course.)

@jbrockmendel, you need to use object PyDatetimeScalarObject as I do in the top PR comment. I suspect you'll need to remove the current PyDatetimeScalarObject cython struct two, to prevent them overlapping.

When I disable

    ctypedef struct PyDatetimeScalarObject:
        # PyObject_HEAD
        npy_datetime obval
        PyArray_DatetimeMetaData obmeta

    ctypedef struct PyTimedeltaScalarObject:
        # PyObject_HEAD
        npy_timedelta obval
        PyArray_DatetimeMetaData obmeta

and in its place put

    ctypedef class numpy.datetime64 [object PyDatetimeScalarObject]:
        cdef npy_datetime obval
        cdef PyArray_DatetimeMetaData obmeta
    
    ctypedef class numpy.timedelta64 [object PyTimedeltaScalarObject]:
        cdef npy_timedelta obval
        cdef PyArray_DatetimeMetaData obmeta

I get compile-time errors below where PyDatetimeScalarObject and PyTimedeltaScalarObject are referenced. Disabling those functions for now numpy compiles, but when running pytest numpy/core/tests/test_cython.py i get compile-time errors for checks.pyx complaining about just about everything in the cnp namespace.

just passing instead of declaring the attributes on datetime64/timedelta64 gives the same errors.