Re: [Cython] [cython-users] Re: New function (pointer) syntax.
On Thursday, November 6, 2014 9:48:53 PM UTC-7, 1989lzhh wrote: > > > > > > 在 Nov 7, 2014，02:56，Robert Bradshaw > > 写道： > > > > [Cc'ing elsewhere for more feedback. Also top-posting for initial > > impressions before the discussion.] > > > > Here's some proposed function pointer syntaxes; which are the most > > obvious to understand/read/remember? Can you figure them out? > > > >cdef float (*F)(float) > >cdef float (*G)(float (*)(float), float, float) > >cdef float ((*H)(char*))(float (*)(float), float, float) > > > > vs > > > >cdef float -> float F > >cdef (float -> float, float, float) -> float G > >cdef (char*) -> (float -> float, float, float) -> float H > > > > vs > > > >cdef lambda float: float F > >cdef lambda (lambda float: float), float, float: float G > >cdef lambda (char*): lambda: (lambda float: float), float, float: > float H > > > > > > If you want a hint, the last is something that returns numerical > > integration algorithm given a string name. Yes, you could use > > typedefs, but you shouldn't have to. especially for the first. > > >Here are numba kind function annotation, I guess it may fit in here. > cdef float(float) F > cdef float(float(float), float, float) G > cdef float(float(float), float, float)(char*) H > I personally feel this kind of annotation is more packed that using ->. > > Regards, > Liu zhenhai > Here are my thoughts, for what they're worth. I actually really like the arrow syntax. It matches the way that the domains and ranges of functions are often written mathematically. On the other hand, it does conflict with the syntax from C. The syntax from Numba is a really good way to do this as well. It is just as clear and doesn't conflict with C. Strictly speaking, it isn't Python, but it would be nice to have similarities in the syntax for the different packages. The C syntax is not intuitive. The only benefit there is the overlap with C. For something this simple, learning the new syntax is easy enough. It will also The lambda syntax strikes me as an intuitive solution, but it isn't particularly clean or concise. If the syntax is going to change, it would be good to change it to something nicer than that. I don't think this one would be worth making the change. All things considered, the Numba syntax looks like the best idea. The arrows are intuitive as well, but the overlap with the syntax from C could be a bad thing. Thanks for looking into this! -Ian Henriksen > > > >> On Thu, Nov 6, 2014 at 9:59 AM, Stefan Behnel > wrote: > >> Robert Bradshaw schrieb am 06.11.2014 um 18:15: > On Thu, Nov 6, 2014 at 12:29 AM, Stefan Behnel wrote: > Robert Bradshaw schrieb am 06.11.2014 um 08:34: > > I'd like to propose a more pythonic way to declare function pointer > > types, namelye > > > >type0 (*[ident])(type1, type2, type3) > > > > would instead become > > > >(type1, type2, type3) -> type0 [ident] > > Not convinced. Looks quite magic, very different from the C that > people > would know, and takes a while reading from left to right until you > see the > "->" which is essentially the only indication of what is happening > here. > >>> > >>> I suppose it depends on whether one knows just C, is familiar with a > >>> wide variety of other (more functional) languages. I think it's a lot > >>> easier for people to read who only know Python, or just a smattering > >>> of C. > >> > >> The thing is, in order to use Cython, you currently only need to > understand > >> Python, some C/C++ and a minor bit of special Cython syntax. The more > new > >> syntax we add outside of Python/C/C++, the higher the entry bar is > raised > >> for both the "mostly Python" and "I know C" users. > > > > True. However, " -> return_annotation" is still Python syntax. > > > Also, "->" has a widely known meaning in C/C++ which makes the above > very > confusing. I think in C when thinking about function pointers, and > there is > no "def ..." keyword indication here that would switch me back to > Python > (as for signature annotations). > > I do see the problem of "where did I have to put that '*' again in > the C > declaration?", but this looks like it will produce more confusion > than it > avoids. > >>> > >>> Hmm, I hadn't thought of that meaning of ->. I don't think it would be > >>> as confusing in context, which will be immediately following cdef or > >>> in a function argument, e.g. one would write > >>> > >>>cdef (float -> float, float, float) -> float integrator = > >>> get_integrator(...) > >> > >> My brain can't even parse that. Does it join as > >> > >>(float -> (float, float, float)) > >> > >> or > >> > >>((float -> float), float, float) > >> > >> ? > > > > The comma token remains lower precedence than about everything else. > > It'
Re: [Cython] New function (pointer) syntax.
On Thu, Nov 6, 2014 at 1:35 PM, C Blake wrote: > I think you should just use the C declarator syntax. Cython already > allows you to say "cdef int *foo[10]". Quick: is that a pointer to an array or 10 pointers to ints? Yes, I know what it is, but the thing is without knowing C (well) it's not immediately obvious what the precedence should be. Cython's target audience includes lots of people who don't know C well. > Declarators aren't bad - just > poorly taught, though I can see some saying those are the same thing. If they were good, they would be easy to learn, no expert teaching required. > More below. I absolutely like the declarator one the most, and the > lambda one second most. Declarator style makes it far easier to take > C code/.h files using function pointers over to Cython. So, this > discussion also depends on whether you view Cython as a bridge to > C libs or its own island/bias toward pure Py3. > > One other proposal that might appease Stefan's "Python lexical cues" > where he was missing "def" would be to take the Python3 function > definition header syntax and strip just variable names. I.e., keep the > ":"s > def foo(x: type1, y: type2, z: type3) -> type0: pass > goes to > (: type1, : type2, : type3) -> type0 [ident] > > I don't think that looks like anything else that might valid in C or > Python. It does just what C does - strip variable names from a function > header, but the ":"s maybe key your brain into a different syntax mode > since they are arguably more rare in C. (Besides stripping names, C has > some extra parens for precedence/associativity - which admittedly are > tuned to make use-expressions simpler than type-expressions.) Anyway, > I don't really like my own proposal above. Just mentioning it for > completeness in case the ":"s help anyone. > > > Robert wrote: >>I really hope, in the long run, people won't have to manually do these >>declarations. > > I agree they'll always be there somehow and also with Stefan's comments > about the entry bar. So, most people not needing them most of the time > doesn't remove the question. > > >>I am curious, when you read "cdef int * p" do you parse this as "cdef >>(int*) p" or "cdef int (*p)" 'cause for me no matter how well I know >>it's the latter, I think the former (i.e. I think "I'm declaring a >>variable of type p that's of int pointer type.") >>[..] >>Essentially everyone thinks "cdef type var" even though that's not >>currently the true grammar. >>[..] >>The reason ctypedefs help, and are so commonly used for with function >>pointers, is because the existing syntax is just so horrendously bad. >>If there's a clear way to declare a function taking a single float and >>returning a single float, no typedef needed. > > No, no, no. Look, generations of C/C++ programmers have been done > monumental disservice by textbooks/code/style guides that suggest > "int* p" is *any less* confusing than spacing "2+3/x" as "2+3 / x". > Early on in my C exposure someone pointed this out and I've never been > confused since. It's a syntax-semantics confusion. Concrete syntax > has always been right associative dereference *. In this syntax family, > the moment any operators []/*/() are introduced, you have to start > formatting it/thinking of it as a real expression, and that formatting > should track the syntax not semantics like in your head "pointer > to"/indirection speak or whatever. syntax != semantics => baddness > Spacing it as if * were left > associative to the type name is misleading at best. > > If you can only think of type decls in general as (type, var) pairs > syntactically and semantically then *of course* you find typedefs more > clear. They make pairing more explicit & shrink the expression tree to > be more trivial. You should *still* space the typedef itself in a way > suggestive of the actual concrete syntax -- "typedef int *p" (or > "ctypedef") just like you shouldn't write "2+3 / x". You should still > not essentially think of "ctypedef type var" *either*, but rather > "typedef basetype expr". In short, "essentially everyone" *should* think > and be taught and have it reinforced and "gel" by spacing that "basetype > expr" is the syntax to create a type-var bindings semantically, and only > perceive "type var" as just one simple case. You are reenforcing the point that declarators are not intuitive, but rather one has to be forcibly hit over the head with them, because they're easy to mis-understand and abuse. > Taking significance of > space in Python/Cython one step further, "int* p" could even be a hard > syntax error, but I'm not seriously proposing that change. :) Distinguishing any "a* b" from "a *b" would be a major change to the tokenizer. Indentation, not all whitespace, is significant. >I really do not think it is "essentially everyone". You know better as you > said anyway, but are in conflict with yourself, I think syntax-semantics > wise. > > Semantically, pointer indirecti
Re: [Cython] [cython-users] Re: New function (pointer) syntax.
On Thu, Nov 6, 2014 at 11:30 PM, Ian Henriksen wrote: > On Thursday, November 6, 2014 9:48:53 PM UTC-7, 1989lzhh wrote: >> >> > 在 Nov 7, 2014，02:56，Robert Bradshaw 写道： >> > >> > [Cc'ing elsewhere for more feedback. Also top-posting for initial >> > impressions before the discussion.] >> > >> > Here's some proposed function pointer syntaxes; which are the most >> > obvious to understand/read/remember? Can you figure them out? >> > >> >cdef float (*F)(float) >> >cdef float (*G)(float (*)(float), float, float) >> >cdef float ((*H)(char*))(float (*)(float), float, float) >> > >> > vs >> > >> >cdef float -> float F >> >cdef (float -> float, float, float) -> float G >> >cdef (char*) -> (float -> float, float, float) -> float H >> > >> > vs >> > >> >cdef lambda float: float F >> >cdef lambda (lambda float: float), float, float: float G >> >cdef lambda (char*): lambda: (lambda float: float), float, float: >> > float H >> > >> > >> > If you want a hint, the last is something that returns numerical >> > integration algorithm given a string name. Yes, you could use >> > typedefs, but you shouldn't have to. especially for the first. >> > >>Here are numba kind function annotation, I guess it may fit in here. >> cdef float(float) F >> cdef float(float(float), float, float) G >> cdef float(float(float), float, float)(char*) H >> I personally feel this kind of annotation is more packed that using ->. >> >> Regards, >> Liu zhenhai > > > Here are my thoughts, for what they're worth. > I actually really like the arrow syntax. It matches the way > that the domains and ranges of functions are often written > mathematically. On the other hand, it does conflict with > the syntax from C. > > The syntax from Numba is a really good way to do this as well. > It is just as clear and doesn't conflict with C. Strictly speaking, > it isn't Python, but it would be nice to have similarities in the > syntax for the different packages. > > The C syntax is not intuitive. The only benefit there is the > overlap with C. For something this simple, learning the new > syntax is easy enough. +1 > The lambda syntax strikes me as an intuitive solution, but it > isn't particularly clean or concise. If the syntax is going > to change, it would be good to change it to something nicer > than that. I don't think this one would be worth making the change. > > All things considered, the Numba syntax looks like the best idea. > The arrows are intuitive as well, but the overlap with the syntax > from C could be a bad thing. Yeah, I'm kind of leaning that way too. > Thanks for looking into this! Thanks for the feedback. - Robert ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython sometimes fails to build on Travis
Hi, Cython sometimes fails to build on Travis for various projects. If it fails, it always ends with this error: https://gist.github.com/certik/08f16dd572170c17d956 Here are some instances of this failure in other projects: https://github.com/sympy/csympy/issues/308 https://github.com/scipy/scipy/pull/4126#issuecomment-62162812 Any ideas what is going on? Thanks, Ondrej ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New function (pointer) syntax.
Robert Bradshaw robertwb at gmail.com wrote:
>Quick: is that a pointer to an array or 10 pointers to ints? Yes, I
>know what it is, but the thing is without knowing C (well) it's not
>immediately obvious what the precedence should be.
If you're gonna pick something e.g like that, it should not be something
people see all the time like int main(int argc, char *argv[]). ;-)
*That* I recognized correctly in far less time than it took me to read
your question text.
Here's a counter: printf("%s", *a[i]) - what does it do? I submit that
if *a[i] is hard or not "real quick" then, eh, what the real problem
here may be that you've got enough syntaxes floating in your brain that
you haven't internalized all the operator rules of this one. In that
case, nothing "operator-oriented" is going to make you truly happy in
the long-run.
I think this whole anti-declarator campaign is misguided. I agree with
Greg that experienced C programmers, such as C library writers know it.
In trying to "fix it", you are just squeezing complexity jello maybe to
oil the squeakiest wheel of casual users. You can eek out a level or
maybe two of simplicity, but you double up syntax. You can make ()s
better and make []s harder..middle-scale complexity better/full scale
a little worse. That kind of thing. The net result of these attempts
doesn't strike me as better or worse except that different is worse.
The closer to exactly C types you can get the more coherent the overall
system is unless/until Python land has a commonly used type setup that
is adequate. The ctypes module has a way to do this and Numba can use
that, though I have little experience doing so. The context is different
in that in Cython you have more opportunity to create new syntax, but
should you do so?
That brings up a totally other note, Could you maybe compile-time eval()
ctypes stuff if you really hate C decls and want to be more pythonic?
If the answer to ctypes is "Err.. not terse/compact/part of the syntax
enough", well, declarators are a fine answer to terseness, that's for
sure. Mostly operator text. ;-)
>Cython's target audience includes lots of people who don't know C well.
One leans differently based on what you think Cython "mostly" is..Bridge
to libs, Its own thing, Compiled python, etc. (I know it's all the above).
>If they were good, they would be easy to learn, no expert teaching required.
All syntax requires learning..e.g, Stefan expressed a harder time than you
visually unpacking some of the "->" exprs. All teaching can be messed up.
Teaching methods can fall into bad ruts. In this case some teaching/practice
actively blocks assimilation..possibly in a long-term sense like mishearing
the lyrics of song or a person's name and then the actual case never sounding
quite right for a long time. Or people with strong accents of your spoken
past dragging you back into accented speech yourself. (Mis-)reinforced
language is *tough* and can transcend good teaching. Part of this thread
was you & Stefan both having an implied question of "why do I read it one
way when I darn well know it's the other". I was trying to help answer
that question. Maybe I'm wrong about your individual case(s). In my
experience with people's trouble is that it's not just "tokens being on
both sides". Most people are used to [] and () being to the right. It's
active mis-reinforcement stuff like spacing/thinking const char instead of
char const,.. that makes it hard. Unless you can avoid declarator style
100%, it's better to make people confront it sooner than do half-measures.
> syntax != semantics => baddness
It's only "misperceived/taught/assimilated semantics"-syntax divergence.
I do consider the misperception unfortunate and unnecessary at the outset.
The "pairing semantics" that "feel" like they diverge from the syntax for
you are 'weak/vague' and *should* have lower priority in your head.
It's only really 1-type, 1-var pairs in function sigs. Even you like
"type varlist" in var or struct decls. I mean, c'mon: "int i, j" rocks. :)
So, it's not always 1-1. Sometimes it's 1-1, sometimes 1-many aka 1 to
a non-trival expr. If you go with a full expression instead of just a
list, you get stuff in return as a bonus..You get stuff and lose stuff.
Declarators are not some hateful, hateful thing to always avoid - there
are pros and cons like anything, not "zero pros except for history" as
you seem to say.
Anyway, "close but different" is the order of the day and is subjective.
Keeping in mind how all three function type cases look - the def/cdef,
call site, type cast/type spec - should be ever present in your syntax
evaluations of all you guys, and so should less trivial cases like
returning a function pointer from a lookup. *Dropping/swapping* parts
is arguably closer than changing how operators work. *New* operators
are better than making old ones multi-personality. I don't like that
cdef char *(..) approach on those grounds. -1 is my $.02.
The
Re: [Cython] Cython sometimes fails to build on Travis
On Fri, Nov 7, 2014 at 5:13 PM, Ondrej Certik wrote: > Hi, > > Cython sometimes fails to build on Travis for various projects. If it > fails, it always ends with this error: > > https://gist.github.com/certik/08f16dd572170c17d956 I don't have any insight into the error, but for CI purposes I install cython with: pip install --install-option="--no-cython-compile" cython which skips the compilation of cython itself (i.e. your cython code is still translated from .pyx to .c, but the cython compiler that does this translation runs as a pure python program). This is ridiculously faster than a normal install -- skipping compiling cython takes minutes off the build, which is far far far more than one loses by making cythonization faster. I mention it here because it seems like aside from being a good idea in general, it might also serve as a workaround for whatever this problem is. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython sometimes fails to build on Travis
Nathaniel Smith schrieb am 07.11.2014 um 23:43: > On Fri, Nov 7, 2014 at 5:13 PM, Ondrej Certik wrote: >> Cython sometimes fails to build on Travis for various projects. If it >> fails, it always ends with this error: >> >> https://gist.github.com/certik/08f16dd572170c17d956 Might be a problem with setuptools, travis, CPython, or even Cython. > I don't have any insight into the error, but for CI purposes I install > cython with: > > pip install --install-option="--no-cython-compile" cython This is definitely the right thing to do for one-time compilations. Also, compiling the resulting C code with CFLAGS="-O0" (or "-O0 -ggdb" etc.) usually gives another speed boost for testing purposes. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New function (pointer) syntax.
On Fri, Nov 7, 2014 at 11:29 AM, C Blake wrote:
> Robert Bradshaw robertwb at gmail.com wrote:
>>Quick: is that a pointer to an array or 10 pointers to ints? Yes, I
>>know what it is, but the thing is without knowing C (well) it's not
>>immediately obvious what the precedence should be.
>
> If you're gonna pick something e.g like that, it should not be something
> people see all the time like int main(int argc, char *argv[]). ;-)
> *That* I recognized correctly in far less time than it took me to read
> your question text.
Yeah, it (coincidentally) parses nicely as (char *) argv[], or an
array of char_ptrs :-P.
> Here's a counter: printf("%s", *a[i]) - what does it do? I submit that
> if *a[i] is hard or not "real quick" then, eh, what the real problem
> here may be that you've got enough syntaxes floating in your brain that
> you haven't internalized all the operator rules of this one. In that
> case, nothing "operator-oriented" is going to make you truly happy in
> the long-run.
>
> I think this whole anti-declarator campaign is misguided. I agree with
> Greg that experienced C programmers, such as C library writers know it.
> In trying to "fix it", you are just squeezing complexity jello maybe to
> oil the squeakiest wheel of casual users. You can eek out a level or
> maybe two of simplicity, but you double up syntax. You can make ()s
> better and make []s harder..middle-scale complexity better/full scale
> a little worse. That kind of thing. The net result of these attempts
> doesn't strike me as better or worse except that different is worse.
I strongly disagree that C declarators are at even a close to an
optimal point in a relatively flat parameter space. Googling "function
pointer syntax" or "c declarator" reinforces the point that this is
one of the most confusing and obtuse aspects of C(++) syntax. But I
admit it's hard to come up with an objective measure for how good a
syntax is...if it's natural to you than that's great.
> The closer to exactly C types you can get the more coherent the overall
> system is unless/until Python land has a commonly used type setup that
> is adequate.
Yes, being like C is an advantage.
> The ctypes module has a way to do this and Numba can use
> that, though I have little experience doing so. The context is different
> in that in Cython you have more opportunity to create new syntax, but
> should you do so?
>
> That brings up a totally other note, Could you maybe compile-time eval()
> ctypes stuff if you really hate C decls and want to be more pythonic?
> If the answer to ctypes is "Err.. not terse/compact/part of the syntax
> enough", well, declarators are a fine answer to terseness, that's for
> sure. Mostly operator text. ;-)
We've considered that, primarily to support as single codebase that
runs un-compiled, but if you cythonize it everything is faster (and,
possibly, more typesafe).
>>Cython's target audience includes lots of people who don't know C well.
>
> One leans differently based on what you think Cython "mostly" is..Bridge
> to libs, Its own thing, Compiled python, etc. (I know it's all the above).
>
>>If they were good, they would be easy to learn, no expert teaching required.
>
> All syntax requires learning..e.g, Stefan expressed a harder time than you
> visually unpacking some of the "->" exprs. All teaching can be messed up.
Teacher: "So to declare a variable of type int, write "int x;"
Stundet: "int x;"
Teacher: "And to declare a variable of type char* write "char *s."
Student: "Oh, I think I see the pattern."
Teacher: "Good, let's move on..."
The fact that there's such an obvious, but erroneous, pattern is (one)
flaw that leads to such confusion.
> Teaching methods can fall into bad ruts. In this case some teaching/practice
> actively blocks assimilation..possibly in a long-term sense like mishearing
> the lyrics of song or a person's name and then the actual case never sounding
> quite right for a long time. Or people with strong accents of your spoken
> past dragging you back into accented speech yourself. (Mis-)reinforced
> language is *tough* and can transcend good teaching.
Very true, but I think it's deeper than that. The problem is that we
*talk* about a variable having type "char*", and the compiler
*reasons* about these more complex types, but the syntax doesn't let
us actually say this directly.
Base types vs. complex types. Empty declarators that hold a place in
the syntax tree but are not seen in the text.
> Part of this thread
> was you & Stefan both having an implied question of "why do I read it one
> way when I darn well know it's the other". I was trying to help answer
> that question. Maybe I'm wrong about your individual case(s). In my
> experience with people's trouble is that it's not just "tokens being on
> both sides". Most people are used to [] and () being to the right. It's
> active mis-reinforcement stuff like spacing/thinking const char instead of
> char const,.. that makes it hard.
