From stefan_ml at behnel.de Mon Sep 4 15:32:43 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 4 Sep 2017 21:32:43 +0200 Subject: [Cython] Safer default exception handling with return type annotations? Message-ID: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> 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() 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. Opinions? Stefan From robertwb at gmail.com Wed Sep 6 01:21:53 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 5 Sep 2017 22:21:53 -0700 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> Message-ID: 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. From stefan_ml at behnel.de Wed Sep 6 01:44:56 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 6 Sep 2017 07:44:56 +0200 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> Message-ID: <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> 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 From robertwb at gmail.com Wed Sep 6 02:28:24 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 5 Sep 2017 23:28:24 -0700 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> Message-ID: 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. From stefan_ml at behnel.de Wed Sep 6 03:06:39 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 6 Sep 2017 09:06:39 +0200 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> Message-ID: <08d81aaf-1316-8d26-fc19-ed016cd11158@behnel.de> 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? It would raise an exception on input, but there would not currently be an error on return. > I think float -> c double but int -> python object will be surprising. I agree. There are two reasons: we don't currently use the int/long Python types anywhere in Cython (which could obviously be changed), and in Python 2, this would exclude "long" objects, which is most likely not intended. So, "int" would probably best refer to "int object or long object" in Python 2, which definitely complicates things. Besides, how many functions can really deal with both "int" and "str" input completely? Your example above is actually a good one, because it would currently return a float object, not "int". But, since it would do the same thing when run in Python, that's probably acceptable. It would need an explicit conversion in both cases, in which case Cython wouldn't need to enforce the type anymore. If "int" is used as input type (or variable declaration), then enforcing it somehow on assignment would be much more relevant. Maybe we should reconsider this whole business when we drop support for Python 2.7. ;) > I also worry a bit > about x: float being enforced but x: List[float] not being so. Interpreting "List[float]" as Cython type "list" would definitely be nice, but note that it would disallow subtypes. In Python, it does not. I think the right way to deal with that, eventually, will be optionally allowing subtypes also in Cython, and handling the distinction more at a case by case basis. Then you could declare a variable as "list" or "List[Any]", and enforce the exact type in the first case but not in the second. And we should definitely use "List[itemtype]" hints also in type inference for loops and indexing at some point. >> 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. I think so, too. For this specific case, we can change the default without breaking backwards compatibility. I also added a new decorator "@exceptval(x, check=False)" for pure mode. If used without arguments as "@exceptval()" or even "@exceptval(check=False)", which seems more readable, users could still get the "write unraisable but don't propagate" behaviour, if they really need it. Stefan From stefan_ml at behnel.de Wed Sep 6 06:53:14 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 6 Sep 2017 12:53:14 +0200 Subject: [Cython] Error handling during buffer reassignment Message-ID: <3d9bc480-d91c-581d-8cba-d88aab08e768@behnel.de> Hi, consider this code: cdef np.ndarray[int32, ndim=1] a a = new_int32_buffer() a = new_float32_buffer() This fails during the second assignment, but only during validation, after unpacking the buffer. The code that handles this case is generated here: https://github.com/cython/cython/blob/c95ca9f21a3524718a83c3415bb7102a508154be/Cython/Compiler/Buffer.py#L376 Note the twist where it says: # If acquisition failed, attempt to reacquire the old buffer # before raising the exception. I faintly remember a discussion about that case (apparently back in 2008), but can't find it in my mail archive. Might have been off-list at the time. Question: Instead of re-acquiring the buffer (and thus faking the non-assignment), wouldn't it be better to acquire the new buffer in a temp, and only overwrite the old "Py_buffer" if all is fine with it? Stefan From robertwb at gmail.com Fri Sep 8 00:36:46 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 7 Sep 2017 21:36:46 -0700 Subject: [Cython] Error handling during buffer reassignment In-Reply-To: <3d9bc480-d91c-581d-8cba-d88aab08e768@behnel.de> References: <3d9bc480-d91c-581d-8cba-d88aab08e768@behnel.de> Message-ID: On Wed, Sep 6, 2017 at 3:53 AM, Stefan Behnel wrote: > Hi, > > consider this code: > > cdef np.ndarray[int32, ndim=1] a > a = new_int32_buffer() > a = new_float32_buffer() > > This fails during the second assignment, but only during validation, after > unpacking the buffer. The code that handles this case is generated here: > > https://github.com/cython/cython/blob/c95ca9f21a3524718a83c3415bb7102a508154be/Cython/Compiler/Buffer.py#L376 > > Note the twist where it says: > > # If acquisition failed, attempt to reacquire the old buffer > # before raising the exception. > > I faintly remember a discussion about that case (apparently back in 2008), > but can't find it in my mail archive. Might have been off-list at the time. > > Question: Instead of re-acquiring the buffer (and thus faking the > non-assignment), wouldn't it be better to acquire the new buffer in a temp, > and only overwrite the old "Py_buffer" if all is fine with it? That makes a lot more sense to me, assuming overwriting is cheap enough. (Can an error happen in releasing the old value?) From robertwb at gmail.com Fri Sep 8 00:51:41 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 7 Sep 2017 21:51:41 -0700 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: <08d81aaf-1316-8d26-fc19-ed016cd11158@behnel.de> References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> <08d81aaf-1316-8d26-fc19-ed016cd11158@behnel.de> Message-ID: On Wed, Sep 6, 2017 at 12:06 AM, Stefan Behnel 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? > > It would raise an exception on input, but there would not currently be an > error on return. > > >> I think float -> c double but int -> python object will be surprising. > > I agree. There are two reasons: we don't currently use the int/long Python > types anywhere in Cython (which could obviously be changed), and in Python > 2, this would exclude "long" objects, which is most likely not intended. > So, "int" would probably best refer to "int object or long object" in > Python 2, which definitely complicates things. > > Besides, how many functions can really deal with both "int" and "str" input > completely? Your example above is actually a good one, because it would > currently return a float object, not "int". But, since it would do the same > thing when run in Python, that's probably acceptable. It would need an > explicit conversion in both cases, in which case Cython wouldn't need to > enforce the type anymore. > > If "int" is used as input type (or variable declaration), then enforcing it > somehow on assignment would be much more relevant. Yes, this was my point. def f(x: float) return x * 2 f("str") would throw an error but def f(x: int) return x * 2 f("str") would not, which seems inconsistent. Also, def f(x: List[float]) return x * 2 f("str") # error f(["str"]) # error? f([1.5]) # ok f([1]) # ok? from some_module import X def g(x: X) return x * 2 g("str") # error? There is a whole can of worms here once one starts "enforcing" these types, partially. I think we need a very clear list of what exactly is supported. Perhaps we should start out with just supporting cython.* and perhaps cimported classes. > Maybe we should reconsider this whole business when we drop support for > Python 2.7. ;) I don't think we'll be able to get rid of 2.7 for quite some time... >> I also worry a bit >> about x: float being enforced but x: List[float] not being so. > > Interpreting "List[float]" as Cython type "list" would definitely be nice, > but note that it would disallow subtypes. In Python, it does not. > > I think the right way to deal with that, eventually, will be optionally > allowing subtypes also in Cython, and handling the distinction more at a > case by case basis. Then you could declare a variable as "list" or > "List[Any]", and enforce the exact type in the first case but not in the > second. > > And we should definitely use "List[itemtype]" hints also in type inference > for loops and indexing at some point. > >>> 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. > > I think so, too. For this specific case, we can change the default without > breaking backwards compatibility. > > I also added a new decorator "@exceptval(x, check=False)" for pure mode. If > used without arguments as "@exceptval()" or even "@exceptval(check=False)", > which seems more readable, users could still get the "write unraisable but > don't propagate" behaviour, if they really need it. +1. Let's make the value required, perhaps with None meaning no value (as it'll never be used). Perhaps check should default to True as well, as the overhead is small (it's an additional check only for exceptions) but more conservative. From stefan_ml at behnel.de Sat Sep 9 06:03:19 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 9 Sep 2017 12:03:19 +0200 Subject: [Cython] Error handling during buffer reassignment In-Reply-To: References: <3d9bc480-d91c-581d-8cba-d88aab08e768@behnel.de> Message-ID: <4b46fe2f-c406-db5c-824e-a48c8210c0a4@behnel.de> Robert Bradshaw schrieb am 08.09.2017 um 06:36: > On Wed, Sep 6, 2017 at 3:53 AM, Stefan Behnel wrote: >> consider this code: >> >> cdef np.ndarray[int32, ndim=1] a >> a = new_int32_buffer() >> a = new_float32_buffer() >> >> This fails during the second assignment, but only during validation, after >> unpacking the buffer. The code that handles this case is generated here: >> >> https://github.com/cython/cython/blob/c95ca9f21a3524718a83c3415bb7102a508154be/Cython/Compiler/Buffer.py#L376 >> >> Note the twist where it says: >> >> # If acquisition failed, attempt to reacquire the old buffer >> # before raising the exception. >> >> I faintly remember a discussion about that case (apparently back in 2008), >> but can't find it in my mail archive. Might have been off-list at the time. >> >> Question: Instead of re-acquiring the buffer (and thus faking the >> non-assignment), wouldn't it be better to acquire the new buffer in a temp, >> and only overwrite the old "Py_buffer" if all is fine with it? > > That makes a lot more sense to me, assuming overwriting is cheap enough. It's just a Py_buffer struct copy. > Can an error happen in releasing the old value? No, releasing buffers is guaranteed to succeed (or rather, to not fail). While working on this, I noticed that there is a difference. Previously, the acquire-release order was: 1) acquire initial buffer 2) on reassign, release old buffer 3) acquire new buffer 4) on failure, re-aqcuire old buffer Now the order is: 1) acquire initial buffer 2) on reassign, acquire new buffer 3) on success, release old buffer Note that the original code never holds two buffers at the same time. I think the old way might have been optimised for that, i.e. it expected success and tried to minimise the potential resource usage, assuming that acquiring and holding a buffer might bind resources of the owner. It's unclear to me whether that assumption holds, but it makes me more hesitant to change the currect implementation. Stefan From stefan_ml at behnel.de Sat Sep 9 13:36:31 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 9 Sep 2017 19:36:31 +0200 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> Message-ID: <04bf53a0-6e71-487b-4ee3-637341d38c20@behnel.de> 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 Stefan From robertwb at gmail.com Sun Sep 10 00:46:27 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 9 Sep 2017 21:46:27 -0700 Subject: [Cython] Safer default exception handling with return type annotations? In-Reply-To: <04bf53a0-6e71-487b-4ee3-637341d38c20@behnel.de> References: <58aef141-5361-a3f4-93a6-6d2925420fac@behnel.de> <6a1191b8-2c72-8050-6ad7-b6d119671b76@behnel.de> <04bf53a0-6e71-487b-4ee3-637341d38c20@behnel.de> Message-ID: On Sat, Sep 9, 2017 at 10:36 AM, Stefan Behnel 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. From stefan_ml at behnel.de Wed Sep 13 02:12:23 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 13 Sep 2017 08:12:23 +0200 Subject: [Cython] Preparing 0.27 Message-ID: <1e183f9c-4e25-2498-3188-ace0a94e31e2@behnel.de> Hi! Current master is starting to feel feature complete for 0.27. If nothing else is pending, I'll prepare an alpha this weekend to collect some feedback on the changes we made. Stefan From stefan_ml at behnel.de Sat Sep 16 05:39:27 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 16 Sep 2017 11:39:27 +0200 Subject: [Cython] Cython 0.27 alpha 1 is available Message-ID: Hi all, Cython 0.27 is nearing completion, so here's an alpha release to get feedback on the many new feature that went in. https://github.com/cython/cython/archive/0.27a1.tar.gz These are the major new features: - PEP 484/526 annotation typing - PEP 525/530 async generators - automatic "__richcmp__()" generation from "__eq__()" & friends - support for Python object references in C++ classes - PGO compilation mode in Jupyter notebooks Plus many little enhancements and bug fixes. For a longer list of improvements, see the changelog: https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst Hope you like it. The timeframe for the final release is hopefully early October. The more feedback we get, the quicker we can prepare it. Stefan From stefan_ml at behnel.de Tue Sep 19 03:49:51 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 19 Sep 2017 09:49:51 +0200 Subject: [Cython] Cython 0.27 beta 1 is available In-Reply-To: References: Message-ID: <4d00a55e-4aa3-6bb6-a2db-9fe7378d3760@behnel.de> Right, I forgot that alpha releases always scream for not being touched. ;) So here's the same thing as beta-1 to get things rolling. https://github.com/cython/cython/archive/0.27b1.tar.gz Changelog: https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst Feedback is appreciated. Stefan Stefan Behnel schrieb am 16.09.2017 um 11:39: > Hi all, > > Cython 0.27 is nearing completion, so here's an alpha release to get > feedback on the many new feature that went in. > > https://github.com/cython/cython/archive/0.27a1.tar.gz > > These are the major new features: > > - PEP 484/526 annotation typing > - PEP 525/530 async generators > - automatic "__richcmp__()" generation from "__eq__()" & friends > - support for Python object references in C++ classes > - PGO compilation mode in Jupyter notebooks > > Plus many little enhancements and bug fixes. For a longer list of > improvements, see the changelog: > > https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst > > Hope you like it. The timeframe for the final release is hopefully early > October. The more feedback we get, the quicker we can prepare it. > > Stefan From jason.madden at nextthought.com Tue Sep 19 07:38:00 2017 From: jason.madden at nextthought.com (Jason Madden) Date: Tue, 19 Sep 2017 06:38:00 -0500 Subject: [Cython] [cython-users] Cython 0.27 beta 1 is available In-Reply-To: <4d00a55e-4aa3-6bb6-a2db-9fe7378d3760@behnel.de> References: <4d00a55e-4aa3-6bb6-a2db-9fe7378d3760@behnel.de> Message-ID: <2C0E6852-3667-474B-94B0-161D594867B1@nextthought.com> > On Sep 19, 2017, at 02:49, Stefan Behnel wrote: > > Right, I forgot that alpha releases always scream for not being touched. ;) > > So here's the same thing as beta-1 to get things rolling. > > https://github.com/cython/cython/archive/0.27b1.tar.gz > > Changelog: > https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst > > Feedback is appreciated. gevent doesn't use any of the new features, but I can confirm that it does build and pass its tests under Python 2.7/3.4/3.6 with Cython 0.27b1. Jason From jdemeyer at cage.ugent.be Tue Sep 19 09:05:06 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Tue, 19 Sep 2017 15:05:06 +0200 Subject: [Cython] Cython 0.27 alpha 1 is available In-Reply-To: References: Message-ID: <59C11602.6000903@cage.ugent.be> Regarding Changelog item * gdb support for Python code (libpython.py) was updated to the latest version in CPython 3.7 (git rev 5fe59f8). Does that fix https://github.com/cython/cython/issues/1655 From stefan_ml at behnel.de Tue Sep 19 10:01:14 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 19 Sep 2017 16:01:14 +0200 Subject: [Cython] Cython 0.27 alpha 1 is available In-Reply-To: <59C11602.6000903@cage.ugent.be> References: <59C11602.6000903@cage.ugent.be> Message-ID: <230bee2e-556b-af06-aa78-2732e9443081@behnel.de> Jeroen Demeyer schrieb am 19.09.2017 um 15:05: > Regarding Changelog item > * gdb support for Python code (libpython.py) was updated to the latest > version in CPython 3.7 (git rev 5fe59f8). > > Does that fix https://github.com/cython/cython/issues/1655 I would guess so. The version shipped with CPython is meant to work across different CPython releases, and was definitely adapted to Py3. Stefan From stefan_ml at behnel.de Tue Sep 19 13:48:31 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 19 Sep 2017 19:48:31 +0200 Subject: [Cython] Big backwards compatibility problem with fused types Message-ID: <039a5edb-9b4e-3c6a-84c4-9c9dac08320a@behnel.de> Hi devs, this is really bad: https://github.com/cython/cython/pull/1873 The problem is that cdef functions with fused types are expanded arbitrarily on use, and their Entries removed and re-appended to the list of cdef function entries. But that list also defines the order of the entries in the vtable! Currently, when a method with fused types is defined in a .pxd file, it is the implementation order in the .pyx (!) file that determines the order in the vtable. Even worse, for modules that cimport from that .pxd file, it is the order in which these methods are *called* that determines the corresponding vtable on the other side, as the entries are expanded at first use, i.e. at their first occurrence in the code, and appended to the current list of cdef functions at this (arbitrary) point. What this means is that there is no way to safely infer the vtable order of an extension type with fused methods from a .pxd file. Now, the correct way to handle this would have been to *replace* the original fused entry with the expanded list of specialised entries. But it's too late for that now. All existing modules out there would need to get recompiled if we changed their vtable order, at least if they use fused any types methods anywhere in their hierarchy. However, I think we can assume code that uses a different method order in the .pxd and .pyx files to be broken already, so a way out of this misery would be to make the .pxd order the one and only source, with the twist that we must keep the "delete and re-append" algorithm to keep the order that existing translated modules are using. Thus the proposal: - we switch to a scheme now that is only defined by the first declaration order, i.e. the order in the .pxd file if there is one. - we make sure all fused methods are expanded in that same order, but continue to follow all non-fused methods in the vtable. - we break all code now that uses a different order of fused methods in their pyx and pxd files Thoughts? Stefan From robertwb at gmail.com Tue Sep 19 16:55:23 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 19 Sep 2017 13:55:23 -0700 Subject: [Cython] Big backwards compatibility problem with fused types In-Reply-To: <039a5edb-9b4e-3c6a-84c4-9c9dac08320a@behnel.de> References: <039a5edb-9b4e-3c6a-84c4-9c9dac08320a@behnel.de> Message-ID: On Tue, Sep 19, 2017 at 10:48 AM, Stefan Behnel wrote: > Hi devs, > > this is really bad: > > https://github.com/cython/cython/pull/1873 > > The problem is that cdef functions with fused types are expanded > arbitrarily on use, and their Entries removed and re-appended to the list > of cdef function entries. But that list also defines the order of the > entries in the vtable! > > Currently, when a method with fused types is defined in a .pxd file, it is > the implementation order in the .pyx (!) file that determines the order in > the vtable. Even worse, for modules that cimport from that .pxd file, it is > the order in which these methods are *called* that determines the > corresponding vtable on the other side, as the entries are expanded at > first use, i.e. at their first occurrence in the code, and appended to the > current list of cdef functions at this (arbitrary) point. > > What this means is that there is no way to safely infer the vtable order of > an extension type with fused methods from a .pxd file. > > Now, the correct way to handle this would have been to *replace* the > original fused entry with the expanded list of specialised entries. But > it's too late for that now. All existing modules out there would need to > get recompiled if we changed their vtable order, at least if they use fused > any types methods anywhere in their hierarchy. > > However, I think we can assume code that uses a different method order in > the .pxd and .pyx files to be broken already, so a way out of this misery > would be to make the .pxd order the one and only source, with the twist > that we must keep the "delete and re-append" algorithm to keep the order > that existing translated modules are using. > > Thus the proposal: > > - we switch to a scheme now that is only defined by the first declaration > order, i.e. the order in the .pxd file if there is one. > > - we make sure all fused methods are expanded in that same order, but > continue to follow all non-fused methods in the vtable. > > - we break all code now that uses a different order of fused methods in > their pyx and pxd files > > Thoughts? +1. We should let the .pxd file, as it is declared, be the source of truth. Code that doesn't already follow this is and does cross-module fused-cdef function calls is already broken. From stefan_ml at behnel.de Wed Sep 20 06:24:29 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 20 Sep 2017 12:24:29 +0200 Subject: [Cython] Big backwards compatibility problem with fused types In-Reply-To: References: <039a5edb-9b4e-3c6a-84c4-9c9dac08320a@behnel.de> Message-ID: Robert Bradshaw schrieb am 19.09.2017 um 22:55: > On Tue, Sep 19, 2017 at 10:48 AM, Stefan Behnel wrote: >> this is really bad: >> https://github.com/cython/cython/pull/1873 >> >> The problem is that cdef functions with fused types are expanded >> arbitrarily on use, and their Entries removed and re-appended to the list >> of cdef function entries. But that list also defines the order of the >> entries in the vtable! >> >> Currently, when a method with fused types is defined in a .pxd file, it is >> the implementation order in the .pyx (!) file that determines the order in >> the vtable. Even worse, for modules that cimport from that .pxd file, it is >> the order in which these methods are *called* that determines the >> corresponding vtable on the other side, as the entries are expanded at >> first use, i.e. at their first occurrence in the code, and appended to the >> current list of cdef functions at this (arbitrary) point. >> >> What this means is that there is no way to safely infer the vtable order of >> an extension type with fused methods from a .pxd file. >> >> Now, the correct way to handle this would have been to *replace* the >> original fused entry with the expanded list of specialised entries. But >> it's too late for that now. All existing modules out there would need to >> get recompiled if we changed their vtable order, at least if they use fused >> any types methods anywhere in their hierarchy. >> >> However, I think we can assume code that uses a different method order in >> the .pxd and .pyx files to be broken already, so a way out of this misery >> would be to make the .pxd order the one and only source, with the twist >> that we must keep the "delete and re-append" algorithm to keep the order >> that existing translated modules are using. >> >> Thus the proposal: >> >> - we switch to a scheme now that is only defined by the first declaration >> order, i.e. the order in the .pxd file if there is one. >> >> - we make sure all fused methods are expanded in that same order, but >> continue to follow all non-fused methods in the vtable. >> >> - we break all code now that uses a different order of fused methods in >> their pyx and pxd files >> >> Thoughts? > > +1. We should let the .pxd file, as it is declared, be the source of > truth. Code that doesn't already follow this is and does cross-module > fused-cdef function calls is already broken. This should fix it: https://github.com/cython/cython/commit/fcc3461e0077c86e30cc81a2fd78bce60f1be007 There were also other problems that I could fix along the way with respect to inheritance from types with fused cdef methods, so I can hope that we're really fixing a rare case in practice. At least, it took more than 5 years after implementing fused types (in April 2012) to discover this bug, so it can't be the most widely used Cython feature out there... Stefan From stefan_ml at behnel.de Sat Sep 23 01:13:43 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 23 Sep 2017 07:13:43 +0200 Subject: [Cython] Cython 0.27 released Message-ID: Hi all, Cython 0.27 is finally out, with several fixes even since the release candidate. This is a major feature release that implements most of the new functionality in Python 3.6, as well as some long awaited Cython language features. https://pypi.python.org/pypi/Cython These are the major new features: - PEP 484/526 annotation typing - PEP 525/530 async generators - automatic "__richcmp__()" generation from "__eq__()" & friends - support for Python object references in C++ classes - PGO compilation mode in Jupyter notebooks Plus many little enhancements and bug fixes. For a longer list of improvements, see the changelog: https://github.com/cython/cython/blob/0.27/CHANGES.rst Hope you like it. Stefan From jpe at wingware.com Mon Sep 25 14:59:01 2017 From: jpe at wingware.com (John Ehresman) Date: Mon, 25 Sep 2017 14:59:01 -0400 Subject: [Cython] Python callable staticmethods? Message-ID: Hi, Is there a way to define a Python callable staticmethod in a Cython cdef class? If not, how hard might this be implement? Thanks, John From stefan_ml at behnel.de Mon Sep 25 15:32:43 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 25 Sep 2017 21:32:43 +0200 Subject: [Cython] Python callable staticmethods? In-Reply-To: References: Message-ID: <3E1920A9-254A-414A-AE75-0724F0F76814@behnel.de> Am 25. September 2017 20:59:01 MESZ schrieb John Ehresman: >Is there a way to define a Python callable staticmethod in a Cython >cdef class? Did you try it? Stefan From jpe at wingware.com Mon Sep 25 15:58:16 2017 From: jpe at wingware.com (John Ehresman) Date: Mon, 25 Sep 2017 15:58:16 -0400 Subject: [Cython] Python callable staticmethods? In-Reply-To: <3E1920A9-254A-414A-AE75-0724F0F76814@behnel.de> References: <3E1920A9-254A-414A-AE75-0724F0F76814@behnel.de> Message-ID: <5e749717-88db-0a36-f446-1ca608538291@wingware.com> On 9/25/17 3:32 PM, Stefan Behnel wrote: > Am 25. September 2017 20:59:01 MESZ schrieb John Ehresman: >> Is there a way to define a Python callable staticmethod in a Cython >> cdef class? > > Did you try it? Not fully, I'll admit. I found that the following are invalid in a .pxd: cdef class Cls: @staticmethod def method(a) @staticmethod cpdef method(a) I later found that just using @staticmethod\n def method(a) in a .py file does work (I'm using pure mode). That means that cython code in other modules is doing a PyObject_GetAttr to get the method and then calling the returned object (admittedly I'm not far enough along to profile to see if this is a real problem or not). I think I'm really asking about cpdef staticmethods. Thanks, John From robertwb at gmail.com Mon Sep 25 20:33:03 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Mon, 25 Sep 2017 17:33:03 -0700 Subject: [Cython] Python callable staticmethods? In-Reply-To: <5e749717-88db-0a36-f446-1ca608538291@wingware.com> References: <3E1920A9-254A-414A-AE75-0724F0F76814@behnel.de> <5e749717-88db-0a36-f446-1ca608538291@wingware.com> Message-ID: On Mon, Sep 25, 2017 at 12:58 PM, John Ehresman wrote: > On 9/25/17 3:32 PM, Stefan Behnel wrote: >> >> Am 25. September 2017 20:59:01 MESZ schrieb John Ehresman: >>> >>> Is there a way to define a Python callable staticmethod in a Cython >>> cdef class? >> >> >> Did you try it? > > > Not fully, I'll admit. I found that the following are invalid in a .pxd: > > cdef class Cls: > > @staticmethod > def method(a) > > @staticmethod > cpdef method(a) > > I later found that just using @staticmethod\n def method(a) in a .py file > does work (I'm using pure mode). That means that cython code in other > modules is doing a PyObject_GetAttr to get the method and then calling the > returned object (admittedly I'm not far enough along to profile to see if > this is a real problem or not). > > I think I'm really asking about cpdef staticmethods. You can write cdef static methods and "def" static methods, but cpdef is not yet supported. From dalcinl at gmail.com Wed Sep 27 08:42:35 2017 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Wed, 27 Sep 2017 15:42:35 +0300 Subject: [Cython] Issue with function annotations Message-ID: $ cython --version Cython version 0.27 $ cat tmp.pyx def f() -> (list, list): return [], [] $ cython tmp.pyx Error compiling Cython file: ------------------------------------------------------------ ... def f() -> (list, list): ^ ------------------------------------------------------------ tmp.pyx:1:12: C struct/union member cannot be a Python object Error compiling Cython file: ------------------------------------------------------------ ... def f() -> (list, list): ^ ------------------------------------------------------------ tmp.pyx:1:12: C struct/union member cannot be a Python object -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 From stefan_ml at behnel.de Wed Sep 27 08:54:07 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 27 Sep 2017 14:54:07 +0200 Subject: [Cython] Issue with function annotations In-Reply-To: References: Message-ID: Hi Lisandro, Lisandro Dalcin schrieb am 27.09.2017 um 14:42: > $ cython --version > Cython version 0.27 > > $ cat tmp.pyx > def f() -> (list, list): > return [], [] > > $ cython tmp.pyx > > Error compiling Cython file: > ------------------------------------------------------------ > ... > def f() -> (list, list): > ^ > ------------------------------------------------------------ > > tmp.pyx:1:12: C struct/union member cannot be a Python object > > Error compiling Cython file: > ------------------------------------------------------------ > ... > def f() -> (list, list): > ^ > ------------------------------------------------------------ > > tmp.pyx:1:12: C struct/union member cannot be a Python object Yes, I noticed that, too. It's a bit annoying. PEP 484 would spell this using the "Tuple" type, i.e. "Tuple[list, list]", or even something like "Tuple[List[Any], List[Any]]". The problem in Cython is that the syntax is reserved for C tuples, which are syntactically nicer structs. "(list, list)" is a struct with two member lists, but since structs do not support reference counting, this is illegal in Cython. The best way to resolve this for now is probably to ignore C tuples in function annotations entirely. At some point, Cython will have to learn to understand complex PEP-484 types like Tuple[]. Stefan From dalcinl at gmail.com Wed Sep 27 09:53:26 2017 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Wed, 27 Sep 2017 16:53:26 +0300 Subject: [Cython] Issue with function annotations In-Reply-To: References: Message-ID: On 27 September 2017 at 15:54, Stefan Behnel wrote: > Hi Lisandro, > > Lisandro Dalcin schrieb am 27.09.2017 um 14:42: >> $ cython --version >> Cython version 0.27 >> >> $ cat tmp.pyx >> def f() -> (list, list): >> return [], [] >> >> $ cython tmp.pyx >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> def f() -> (list, list): >> ^ >> ------------------------------------------------------------ >> >> tmp.pyx:1:12: C struct/union member cannot be a Python object >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> def f() -> (list, list): >> ^ >> ------------------------------------------------------------ >> >> tmp.pyx:1:12: C struct/union member cannot be a Python object > > Yes, I noticed that, too. It's a bit annoying. PEP 484 would spell this > using the "Tuple" type, i.e. "Tuple[list, list]", or even something like > "Tuple[List[Any], List[Any]]". > > The problem in Cython is that the syntax is reserved for C tuples, which > are syntactically nicer structs. "(list, list)" is a struct with two member > lists, but since structs do not support reference counting, this is illegal > in Cython. > > The best way to resolve this for now is probably to ignore C tuples in > function annotations entirely. At some point, Cython will have to learn to > understand complex PEP-484 types like Tuple[]. > Stefan, I think you are mixing things up. Annotations can be used for type hinting, but they are not required to do that. For example, in my own use case, I'm just using it to get better docstrings. In this commit: commit 806e2fe6eefea5bfa011a45ea556d93c2094a95a Author: Stefan Behnel Date: Sat Sep 2 21:01:28 2017 +0200 Disable an "embedsignatures" test that is not actually valid with PEP 484 but fails to compile as the return type now interpreted as a C-tuple of Python objects (which is not supported). You disabled one of my test case. This test case is about docstrings, not type hints! I wrote that test on purpose, to prevent regressions. At the time I wrote the example, IIRC, annotation_typing=False was the default. At most, we should add `#cython: annotation_typing=False` in the top, and Cython should happily accept the code and the test should succeed. I can try to contribute a fix. I would like to ignore C-tuples in annotations at least if annotation_typing=False. Any pointers about where to start looking? -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 From stefan_ml at behnel.de Wed Sep 27 10:18:58 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 27 Sep 2017 16:18:58 +0200 Subject: [Cython] Issue with function annotations In-Reply-To: References: Message-ID: <2cbf2cb0-1e98-2b90-aaa2-324f36f5bbfc@behnel.de> Lisandro Dalcin schrieb am 27.09.2017 um 15:53: > Annotations can be used for > type hinting, but they are not required to do that. Well, they sort of are, according to PEP 484. > For example, in my > own use case, I'm just using it to get better docstrings. Then you can set the directive "annotation_typing=False". > In this commit: > > commit 806e2fe6eefea5bfa011a45ea556d93c2094a95a > Author: Stefan Behnel > Date: Sat Sep 2 21:01:28 2017 +0200 > > Disable an "embedsignatures" test that is not actually valid with > PEP 484 but fails to compile as the return type now interpreted as a > C-tuple of Python objects (which is not supported). > > You disabled one of my test case. This test case is about docstrings, > not type hints! I wrote that test on purpose, to prevent regressions. > At the time I wrote the example, IIRC, annotation_typing=False was the > default. At most, we should add `#cython: annotation_typing=False` in > the top, and Cython should happily accept the code and the test should > succeed. > > I can try to contribute a fix. I would like to ignore C-tuples in > annotations at least if annotation_typing=False. Any pointers about > where to start looking? No need, I just fixed it: https://github.com/cython/cython/commit/4326a3b9912e27aaf9502e17d717b55b7504374a Stefan From stefan_ml at behnel.de Wed Sep 27 15:12:10 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 27 Sep 2017 21:12:10 +0200 Subject: [Cython] 0.27.1 beta Message-ID: Hi all, the new features in 0.27 introduced a couple of regressions that Robert and I have been hunting down during the last days. Thanks everyone for reporting bugs and helping to isolate them. I will release a bug fix version this weekend, so here is a beta to see if we caught everything - or broke something new. :) https://github.com/cython/cython/archive/0.27.1b1.tar.gz Changelog: https://github.com/cython/cython/blob/0.27.1b1/CHANGES.rst Please give it some testing. Thanks, Stefan From dalcinl at gmail.com Thu Sep 28 04:44:24 2017 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Thu, 28 Sep 2017 11:44:24 +0300 Subject: [Cython] Issue with function annotations In-Reply-To: <2cbf2cb0-1e98-2b90-aaa2-324f36f5bbfc@behnel.de> References: <2cbf2cb0-1e98-2b90-aaa2-324f36f5bbfc@behnel.de> Message-ID: On 27 September 2017 at 17:18, Stefan Behnel wrote: > Lisandro Dalcin schrieb am 27.09.2017 um 15:53: >> Annotations can be used for >> type hinting, but they are not required to do that. > > Well, they sort of are, according to PEP 484. > I gently disagree. Third paragraph of PEP 484: """ Note that this PEP still explicitly does NOT prevent other uses of annotations, nor does it require (or forbid) any particular processing of annotations, even when they conform to this specification. """ Maybe Cython should eventually ignore (maybe with a warning) if the annotation cannot be interpreted as a type and `annotation_typing=True` is set? > >> For example, in my >> own use case, I'm just using it to get better docstrings. > > Then you can set the directive "annotation_typing=False". > I did in my own code (though not in the trivial example I posted, sorry), and still got the error, so I started this thread. > > > No need, I just fixed it: > > https://github.com/cython/cython/commit/4326a3b9912e27aaf9502e17d717b55b7504374a > Thanks! Now things work just fine for me. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 From jdemeyer at cage.ugent.be Thu Sep 28 05:32:31 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Thu, 28 Sep 2017 11:32:31 +0200 Subject: [Cython] Website still mentions Python 3.2 Message-ID: <59CCC1AF.6070203@cage.ugent.be> I think that this sentence on cython.org is outdated: The C code is generated once and then compiles with all major C/C++ compilers in CPython 2.6, 2.7 (2.4+ with Cython 0.20.x) as well as 3.2 and all later versions. From stefan_ml at behnel.de Thu Sep 28 05:51:32 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 28 Sep 2017 11:51:32 +0200 Subject: [Cython] Website still mentions Python 3.2 In-Reply-To: <59CCC1AF.6070203@cage.ugent.be> References: <59CCC1AF.6070203@cage.ugent.be> Message-ID: <5068ef42-5918-b8d7-7e63-6b22e84384d8@behnel.de> Jeroen Demeyer schrieb am 28.09.2017 um 11:32: > I think that this sentence on cython.org is outdated: > > The C code is generated once and then compiles with all major C/C++ > compilers in CPython 2.6, 2.7 (2.4+ with Cython 0.20.x) as well as 3.2 and > all later versions. Replaced with 3.3. Thanks! Stefan