Re: [Cython] Safer default exception handling with return type annotations?
On Mon, Sep 4, 2017 at 12:32 PM, Stefan Behnel wrote:
> Hi all,
>
> since PEP 484 type annotations are scheduled for the next release now, I
> wonder if we should take the opportunity to change the defaults for the
> exception handling of typed cdef functions.
>
> Currently, if you define a function like this:
>
> cdef int func():
> raise ValueError()
>
> It will not actually raise the error but print and ignore it. In order to
> make it safe, you have to say
>
> cdef int func() except -1:
> raise ValueError()
A huge +1 to making exception propagation implicitly the default.
(Would we want to introduce syntax to preserve the old behavior
though?) There is the downside of a slight performance regression (we
should measure exactly how slight) and leaving the exception set
(which could actually be desirable) but exception swallowing is almost
never what a user wants.
> It has always been like this, but with PEP 484 type annotations, it becomes
> much nicer to keep Cython code Python compatible and actually running in
> Python, so that the following is safe when interpreted but not when compiled:
>
> @cython.cfunc
> def func(x: cython.int) -> cython.int:
> if x < 0:
> raise ValueError()
> return x * 2
>
> Since this is new syntax, and no code exists yet that uses it, it would be
> safe to change the default here, and to automatically declare this function
> as "except? -MIN_INT", for example. The same applies to functions returning
> pointers ("except? NULL") or even structs, which could be declared "except *".
>
> This would lead to inconsistencies within Cython, but I think the use case
> of Python compatible behaviour is important enough to consider this, and
> for code using this syntax, it also feels less likely that the caller is
> actual C code that couldn't handle that exception.
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.
I would be willing to consider letting un-annotated extern functions
have different defaults than non-extern ones. This would, of course,
make the two type signatures incompatible (though presumably an
except? could be used wherever a noexcept one is needed.
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Safer default exception handling with return type annotations?
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. 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, 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. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Safer default exception handling with return type annotations?
On Tue, Sep 5, 2017 at 10:44 PM, Stefan Behnel 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. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
