(@cython.cfunc + Type Annotation) Fragility #2529
Going through some of pandas' cython modules to try to make code valid-python where possible, I'm seeing cythonize-time errors. It seems like some combinations are invalid for surprising reasons, e.g:
Another example with a slightly different set of errors:
This last one here is the one that is noticeably different from the first example.
Is this behavior intentional?
The text was updated successfully, but these errors were encountered:
Thanks for that list (and for trying it in the first place). It means we clearly lack tests here, and it's good to have real-world feedback about where people encounter real-world problems.
Regarding the "obvious" cases:
This can never work, because
There is an
@cython.cfunc @cython.inline def is_null_datetime64(v) -> bint:
There is a (similar) test for this in our test suite, so I don't know right now why this would fail. Probably something trivial.
@cython.ccall def get_rule_month(source: object, default: object='DEC') -> object:
which also fails for you, as you said. I remember noticing this kind of error, too, and fixing something in that corner recently. Could you try the latest master on that?
Possibly relevant: there is an accompanying .pxd file that was unchanged throughout all these iterations with "cdef bint is_null_datetime64(v)`
Will do. I'll also add to the list permutations involving
Good to know, thanks. My intuition was that the parser would translate each of the supported forms to a canonical representation, allowing users to mix and match (even though doing so would be really weird in some cases). Not the first time intuition has led me astray. (Can you point me towards the part of the code responsible for this? If it doesn't require learning the entire code-base, I'd be happy to help with fleshing out the tests)
A use case I can imagine where this would be really convenient is linting (a large part of the motivation for trying this syntax in the first place). With
Ah, yes, I'd be surprised if that didn't make a difference. But if you have a
There are different aspects to this. One is the
Tests for this ended up in the pure Python mode tests (
For the first part, use
For the second, there isn't currently a way to use
Not sure how this status quo developed; presumably easier for contributors/reviewers if they match.
This runs into a "if it were up to me..." issue where its hard to predict what maintainers will or won't have a strong opinion about. Last time I tried to move to the decorator syntax the idea was shot down. It's totally reasonable if you want to declare that Not Cython's Problem.
As for the
I'll install from master and update results in a bit.
Installed from master, no apparent change:
Some more cases, these without an accompanying pxd file:
So it looks like there exists no valid way to use type annotations on this function.
A weird thing a user might do is mix/match (here using type annotation only for the
Of course the
But even with the memoryview syntax it chokes:
Now one with an
Thanks for testing these.
I improved the error message for these.
This is a bug and should work.
These are not valid Python syntax (note that you say
This is a missing feature. I created #2557 for it.
This is a bug and should work. (fixed in 7bebbdd)
I improved the error message for this one.
…ons on cdef functions. See #2529.
…f functions. See #2529.
…nction syntax. See #2529.
Trying out 0.29
Tried changing this in the accompanying pxd to match
I'm having the similar issues on cython V0.29 with return types in the .pyx file. Any python object return type breaks compilation in python compatible mode. Cython types work for returns (int, float, cython.int, cython.void, etc), np.ndarray and python builtins don't.
Also returning None gives a different error:
which makes it not compatible with typed python even with just builtin types. If returning None is redundant, can cython just ignore it? or alias it to a cython void / NULL? (Should this be a separate issue?)
It's mention in the docs (or rather inspired by
@cython.cfunc def foo(s) -> unicode: return unicode(s)
doesn't work, while this does:
cdef unicode foo(s): return unicode(s)
def foo(s) -> unicode: return unicode(s)
compiles fine, and to the same code as
The same goes with
@cython.cfunc def foo(s) -> str: return str(s)
All of that shouldn't be a new info, but rather additional use/test cases
OK all cases raising exception:
@cython.ccall def get_rule_month(source: object, default: object='DEC') -> object: @cython.cfunc def foo(s) -> str: @cython.cfunc def foo(s) -> unicode:
Exception is raised here:
The root cause of it is following (
And basically it boils down to principle:
I have pretty simple solution for this issue, PR will be created.