[Cython] Safer default exception handling with return type annotations?

Robert Bradshaw robertwb at gmail.com
Wed Sep 6 02:28:24 EDT 2017


On Tue, Sep 5, 2017 at 10:44 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw schrieb am 06.09.2017 um 07:21:
>> I'm not a huge fan of behaving differently depending on what syntax
>> was used to annotate the return type--I'd rather they be 100% aliases
>> of each other.
>
> Regarding this bit - I already chose to implement some differences for
> annotation typing. Mainly, if you say
>
>     def f(x: int) -> float:
>         return x
>
> then the (plain "def") function will actually be typed as "double
> f(object)"., assuming that you probably meant the Python types and not the
> C types. If you want the C types "int" and "float", you have to use either
> of these:
>
>     def f1(x: cython.int) -> cython.float:
>         return x
>
>     cpdef float f2(int x):
>         return x
>
> That is because the main use case of signature annotations is Python code
> compatibility, so I tried to change the semantics as little as possible
> from what the code would be expected to do in Python.

What about

def f(x: float) -> int
  return x * 2

would that throw an error if x was, say, a str? I think float -> c
double but int -> python object will be surprising. I also worry a bit
about x: float being enforced but x: List[float] not being so.

> I also considered if distinguishing between .py and .pyx files would make
> sense here, but adapting the type interpretation to that felt much worse
> than the above,

Agreed, -1 to doing this.

> which is at least consistent regarding the typing scheme
> that you use.
>
> I think this type interpretation is a reasonable, use case driven
> difference to make. Thus my question if we should extend this to the
> exception declaration.

I suppose you've already made a case for deviating...

I guess I think it'd be nice to change the default universally, but
that's perhaps a bigger conversation.


More information about the cython-devel mailing list