Hi,
To follow up in more detail:
>> *1) Main question*
>> *COMPILES*: Using lower-case PEP-585 types with cdef
>> cdef list[str] list_return():
>> return ["foo"]
I'm actually surprised this works. I'm not sure what it'll deduce the
return type as
>>
>> *DOESN'T COMPILE*: "list[str] is not a type"
>> @cython.cfunc
>> def list_return() -> list[str]:
>> return ["foo"]
>>
>> Is there a reason why it doesn't work with the decorator style, or am I
>> doing something wrong here?
We haven't implemented subscripting list, tuple, dict, etc directly
yet. It probably isn't too hard but I wouldn't expect this to work on
the current branch.
>>
>> For some reason, typing.List has never worked for me, using either
>> cpdefs
>> or @cython.cfunc. For example:
>>
>> *DOESN'T COMPILE:* 'List' is not a type identifier
>> from typing import List
>> cpdef List[str] list_return():
>> return ["foo"]
This should work with the current master build (but it hasn't yet made
it into a release). There's a bit of tidying still to (which I think is
why it hasn't made it into a release). The element type (`str`) isn't
currently used for anything (but no reason not to include it).
>>
>> list_type: TypeAlias = list[str]
>> @cython.cfunc
>> def list_return() -> list_type:
>> return ["foo"]
We don't currently support this.
>>
>> *4) Long term support?*
>> In the long run, will more complex parameterized generic types be
>> supported
>> inside cdefs (and presumably also for @cython.cfunc)?
>>
>> a) dict[str, list[int]] or dict[str, set[int]]
>> b) address: TypeAlias = dict[str, list[int]]
>> c) list[str | int]
a) right now we don't do anything with the subscripted types (except for
tuples). `typing.Dict[str, typing.List[int]]` will work now (but is the
same as `dict` from Cython's point-of-view). We'd probably aim to
support the versions you've written (without the typing import) fairly
soon. I don't think we've decided what the long-term plan for using the
element types is...
b) Not sure. Probably...
c) Probably in future, but most likely only as `list`. We may well end
up using union types as fused types (but probably only in fairly limited
circumstances, like if the union type is used directly as a function
argument). We'd probably start with `typing.Union[...]` and then add the
newer `str | int` syntax later.
Hopefully that's helpful,
David