Robert Bradshaw schrieb am 06.11.2014 um 19:56: > On Thu, Nov 6, 2014 at 9:59 AM, Stefan Behnel wrote: >> Robert Bradshaw schrieb am 06.11.2014 um 18:15: >>> This becomes especially clear for return types, e.g. >>> >>> cdef ((float -> float, float, float) -> float) >>> get_integrator(char* algorithm): >>> if algorithm == ... >>> >>> vs >>> >>> cdef float (*get_integrator(char* algorithm))(float (*)(float), >>> float, float): >>> if algorithm == ... >> >> Same thing as above. The nesting is clearer in the latter. > > Clearly we think differently... I can pick apart the latter > definition, but I have to admit it took a lot longer to type than the > former, and I still see "cdef float blah(...., float, float): ..." > when in fact I'm declaring something that takes a char* (or should > that read, "takes something that dereferences to a char" :-)).
I already said that C function types have their own quirks - I keep writing (func*) instead of (*func), for example. It feels just arbitrary and fails to stick in my head. But "->" is too well known as an operator when it comes to pointers (which function types are in C) to provide for a *more* readable alternative. Just because some functional languages use it in some specific way doesn't mean it fits into a language that mixes Python and C. > I am curious, when you read "cdef int * p" do you parse this as "cdef > (int*) p" or "cdef int (*p)" Definitely the former. And the complexity that some type declarations can take in C (let alone C++) is just devastating. Problem is, any new syntax in Cython will have to co-exist with the existing (C) syntax potentially forever, and will add to the language learning curve. People will learn one syntax, but have to understand the second syntax in order to read other people's code. And others will start adopting the new syntax in code that uses the old syntax without cleaning up first. If we go that route of adding yet another syntax, it needs to be an obvious one from both a "C with Python features and syntax" and a "Python with C datatypes" point of view. In short, it has to fit into the existing language mix. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
