On Sat, Sep 9, 2017 at 10:36 AM, Stefan Behnel <stefan...@behnel.de> wrote: > Robert Bradshaw schrieb am 06.09.2017 um 08:28: >> 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. > > What do you think of this? > > https://github.com/cython/cython/pull/1865
Makes sense to me. _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
