On Tue, Sep 5, 2017 at 10:44 PM, Stefan Behnel <stefan...@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. _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
