Re: [Cython] Error handling during buffer reassignment
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 ___ 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 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 ___ 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 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. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
