Declaration syntax change
In thinking about 1.0, this would be a chance to make backwards-incompatible changes. One thing that has always bothered me is the C-delclarator decoration for specifying complex types. Specifically, cdef int *a, b, c, *d[3] is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required cdef int* a cdef int b, c cdef int[3]* d In this case our grammar could be almost identical to the Python grammar, with the addition of a "type declaration" that could occur in certain situations plus a new type token. Does anyone see any issues with this? We could have a period where we warned if declarators were used, or simply disallow them outright before changing the meaning. It'd be easy to create a tool one could run on your sources that would "expand" such declarations as well. - Robert
Robert Bradshaw, 03.10.2013 05:38:
In thinking about 1.0, this would be a chance to make backwards-incompatible changes. One thing that has always bothered me is the C-delclarator decoration for specifying complex types. Specifically,
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
I think we've tossed this around long enough to consider it set.
In this case our grammar could be almost identical to the Python grammar, with the addition of a "type declaration" that could occur in certain situations plus a new type token.
I don't expect the parser/grammar simplifications to be all that large. There are still cdef functions, C function pointers and typed function argument lists, for example, which will stay as they are and involve quite a bit of parsing complexity all by themselves. Only type declaration statements would benefit. I guess we should give it a try in a branch to see what the code gain is. There may still be a couple of nasty little details.
We could have a period where we warned if declarators were used, or simply disallow them outright before changing the meaning.
If that means that people get urged into manually changing their code to have one variable declaration per line in order to be future proof, then that's asking a bit too much, I think. Better do a clean cut and provide a tool that migrates the code to the next Cython major release. We've always encouraged people not to depend on Cython in released sources, so the situation is very different from the Py2/3 change where people necessarily needed to support older versions.
It'd be easy to create a tool one could run on your sources that would "expand" such declarations as well.
Yes, we should definitely provide something here. I'm pretty sure this change is going to require modifications to almost all Cython code out there. (Then again, if we actually break all that code anyway, maybe there are other things to change as well? I'm not aware of any...) Stefan
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
What would be the benefit of this? You're proposing to change from something identical to C declaration syntax, which is second nature for a great many people, to something that looks deceptively like C syntax but isn't. I can't see that causing anything other than a massive amount of confusion, anguish and hair-tearing. -- Greg
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users.
What would be the benefit of this? You're proposing to change from something identical to C declaration syntax, which is second nature for a great many people, to something that looks deceptively like C syntax but isn't.
The reasoning is that the C syntax is error prone and less readable than it could be, because you have to spot stars in the right places of a potentially long list of variable names to know if something is a value or a pointer. If there was only one type declaration, right after the cdef, it would be much clearer. It would just say: "this is a list of variables declared as int*", not mixing any further types into it. Also, C is only second nature to some people. A great many people actually use Cython specifically to *avoid* having to write C. Stefan
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users.
What would be the benefit of this? You're proposing to change from something identical to C declaration syntax, which is second nature for a great many people, to something that looks deceptively like C syntax but isn't.
The reasoning is that the C syntax is error prone and less readable than it could be, because you have to spot stars in the right places of a potentially long list of variable names to know if something is a value or a pointer. If there was only one type declaration, right after the cdef, it would be much clearer. It would just say: "this is a list of variables declared as int*", not mixing any further types into it.
Also, C is only second nature to some people. A great many people actually use Cython specifically to *avoid* having to write C.
The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...? (I'm not against improving on C in general, but I'm far from convinced that there's any syntax for encoding C types that's sufficiently better than what C does to be worth the switching costs.) If what really bothers you is having objects of different types declared within the same statement then you could just litigate *that* out of existence directly... not convinced this would be worthwhile (though I do tend to use that style myself already), but it seems more viable than trying to reinvent C's type syntax. -n
Nathaniel Smith, 03.10.2013 14:35:
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users. [...] The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote: there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...?
Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm just confused (by both, actually) because I'm not really breathing C. If the following is what it's supposed to mean, then I find it quite straight forward, and more obvious than the C spelling: cdef int* a # pointer to int cdef int[3]* b # pointer to 3-item int array cdef int*[3] c # 3-item array of pointers to int I agree that the argument of "copying it out of a header file" has a certain value, although pointer declarations are not exactly the most common thing to find in header files. We shouldn't make it *harder* to copy things from header files, though, because it's already a drawback of Cython that you have to do that at all. Stefan
On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Nathaniel Smith, 03.10.2013 14:35:
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users. [...] The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote: there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...?
Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm just confused (by both, actually) because I'm not really breathing C.
Yeah, personally in either case I'd have to look it up (and it's simply impossible that you're going to make it as easy to lookup this funky Cython-specific syntax as it is to look up standard C syntax). But also, the reason I don't know the C version already is that I've probably never seen such a declaration in real life, which makes it hard to see why this is a really pressing problem. I don't really come to Cython because I want idiosyncratic tweaks to things C already does perfectly well, you know? I come to Cython because I want a nice way to get Python and C to talk to each other, so sticking to familiar Python and C things is rather nice... -n
On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Nathaniel Smith, 03.10.2013 14:35:
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required
cdef int* a cdef int b, c cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users. [...] The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote: there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...?
Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm just confused (by both, actually) because I'm not really breathing C.
Yeah, personally in either case I'd have to look it up (and it's simply impossible that you're going to make it as easy to lookup this funky Cython-specific syntax as it is to look up standard C syntax). But also, the reason I don't know the C version already is that I've probably never seen such a declaration in real life, which makes it hard to see why this is a really pressing problem.
Cause or effect :).
I don't really come to Cython because I want idiosyncratic tweaks to things C already does perfectly well, you know?
I wouldn't classify this as something that "C already does perfectly well." The fact that people commonly write int* ptr; rather than int *ptr; means that it's parsed differently in people's heads than the grammar, and though it's hard to miss given the context of this thread I've seen people gloss right over things like char* a, b; a = malloc(n); b = malloc(n); strcpy(b, a); which, yes, is perfectly valid C (though any sane compiler will throw out a warning). It should also be noted that an increasing percentage of Cython users don't know C at all. The rule would be very simple--type decorations would be left associative, so an int*[5]** would be a pointer to a pointer to an array of pointers to ints. Now, you're right that this doesn't come up often, which is why it'll be easy to change, but it does complicate the compiler (and hypothetical grammar). Ideally people shouldn't be copying C headers in the long run, they should be parsed automatically or by wrappers like xdress. This would affect all variable declarations. E.g. cdef int *foo(int* a[3], int (*b)[3]): ... would become cdef int* foo(int*[3] a, int[3]* b): ... or cdef int* foo(a : int*[3], b : int[3]*): ... or even cdef foo(a : int*[3], b : int[3]*) -> int*: ... (those last two being rather hypothetical) and ctypedef double point[3] would become ctypedef double[3] point Function pointers are a bit harder, but cdef double (*f)(int, long) could become cdef double (*)(int, long) f unless we wanted to introduce something totally new like cdef (int, long) -> double f following Python return value annotation syntax (which is new, but quite transparent in meaning). - Robert
On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw <robertwb@gmail.com> wrote:
On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Nathaniel Smith, 03.10.2013 14:35:
Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote: > cdef int *a, b, c, *d[3] > > is IMHO quite ugly but also adds a lot of complexity to the parser. > What if instead we required > > cdef int* a > cdef int b, c > cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users. [...] The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote: there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...?
Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm just confused (by both, actually) because I'm not really breathing C.
Yeah, personally in either case I'd have to look it up (and it's simply impossible that you're going to make it as easy to lookup this funky Cython-specific syntax as it is to look up standard C syntax). But also, the reason I don't know the C version already is that I've probably never seen such a declaration in real life, which makes it hard to see why this is a really pressing problem.
Cause or effect :).
I don't really come to Cython because I want idiosyncratic tweaks to things C already does perfectly well, you know?
I wouldn't classify this as something that "C already does perfectly well." The fact that people commonly write
int* ptr;
rather than
int *ptr;
means that it's parsed differently in people's heads than the grammar, and though it's hard to miss given the context of this thread I've seen people gloss right over things like
char* a, b; a = malloc(n); b = malloc(n); strcpy(b, a);
which, yes, is perfectly valid C (though any sane compiler will throw out a warning). It should also be noted that an increasing percentage of Cython users don't know C at all.
So, like I said upthread, if this is the problem you're really trying to solve, just tackle it directly by making 'char *a, b' an error of some kind.
The rule would be very simple--type decorations would be left associative, so an int*[5]** would be a pointer to a pointer to an array of pointers to ints.
That's a simple rule, but not necessarily a memorable one -- it's exactly the opposite of how both English and C work. English: you'd say "array of pointers" but write pointer-array *[]. C: *const * is a const-pointer-to-pointer, but here it would be a pointer-to-const-pointer. In real life of course I'd parenthesize an expression like this to make it unambiguous even for readers who don't remember the precedence/associativity rules, but I guess in this notation you can't parenthesize things, readers will have to memorize/look-up the associativity regardless.
Now, you're right that this doesn't come up often, which is why it'll be easy to change, but it does complicate the compiler (and hypothetical grammar). Ideally people shouldn't be copying C headers in the long run, they should be parsed automatically or by wrappers like xdress.
But we don't live in the long run. Maybe that will happen eventually, maybe it won't -- it's hard to make predictions, especially about the future... -n
On Thu, Oct 3, 2013 at 10:21 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw <robertwb@gmail.com> wrote:
On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Nathaniel Smith, 03.10.2013 14:35:
Greg Ewing, 03.10.2013 14:10: > Robert Bradshaw wrote: >> cdef int *a, b, c, *d[3] >> >> is IMHO quite ugly but also adds a lot of complexity to the parser. >> What if instead we required >> >> cdef int* a >> cdef int b, c >> cdef int[3]* d
The last line looks ambiguous, BTW, hadn't even noticed it before. Is that an array of int pointers or a pointer to an array (pointer)? We should make sure the way this is declared is really obvious and not unexpected to C users. [...] The two halves of this email seem to sort of contradict each other, don't you think? At least the C syntax has the advantage that it's well-defined and many people *do* know it (and if they don't then
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote: there are bazillions of references around, plus you can just copy it out of header files if you're wrapping a C library), whereas as noted above, in fact there are *no* people who know how to look at int[3]* and be confident about what it means, even you...?
Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm just confused (by both, actually) because I'm not really breathing C.
Yeah, personally in either case I'd have to look it up (and it's simply impossible that you're going to make it as easy to lookup this funky Cython-specific syntax as it is to look up standard C syntax). But also, the reason I don't know the C version already is that I've probably never seen such a declaration in real life, which makes it hard to see why this is a really pressing problem.
Cause or effect :).
I don't really come to Cython because I want idiosyncratic tweaks to things C already does perfectly well, you know?
I wouldn't classify this as something that "C already does perfectly well." The fact that people commonly write
int* ptr;
rather than
int *ptr;
means that it's parsed differently in people's heads than the grammar, and though it's hard to miss given the context of this thread I've seen people gloss right over things like
char* a, b; a = malloc(n); b = malloc(n); strcpy(b, a);
which, yes, is perfectly valid C (though any sane compiler will throw out a warning). It should also be noted that an increasing percentage of Cython users don't know C at all.
So, like I said upthread, if this is the problem you're really trying to solve, just tackle it directly by making 'char *a, b' an error of some kind.
The rule would be very simple--type decorations would be left associative, so an int*[5]** would be a pointer to a pointer to an array of pointers to ints.
That's a simple rule, but not necessarily a memorable one -- it's exactly the opposite of how both English and C work. English: you'd say "array of pointers" but write pointer-array *[]. C: *const * is a const-pointer-to-pointer, but here it would be a pointer-to-const-pointer.
Actually, this is like English. "Int pointer" or "int array pointer" where the preceding words describe the kind of pointer you have. (it can be inverted of course, key board = board of keys, stack pointer = pointer to the stack, etc.) Const is a pain, but I'd say it binds tighter than anything else and cannot be mixed with the other declarators to follow C conventions. E.g. "const int*" points to a const int, and "const (int*)" points to an int but can't be changed.
In real life of course I'd parenthesize an expression like this to make it unambiguous even for readers who don't remember the precedence/associativity rules, but I guess in this notation you can't parenthesize things, readers will have to memorize/look-up the associativity regardless.
Yes, write (((int*)[5])*)* will be supported, just as one can write (((a - b) - c) - c) instead of a - b - c - d.
Now, you're right that this doesn't come up often, which is why it'll be easy to change, but it does complicate the compiler (and hypothetical grammar). Ideally people shouldn't be copying C headers in the long run, they should be parsed automatically or by wrappers like xdress.
But we don't live in the long run. Maybe that will happen eventually, maybe it won't -- it's hard to make predictions, especially about the future...
Maybe this'll be additional motivation :). But as has been mentioned they don't come up often in real life, but do have an oversized presence in the compiler/grammar. Whatever script is provided to clean up existing .pxd files could be used to transform copy-pasted header declarations. - Robert
Greg Ewing wrote:
What would be the benefit of this? You're proposing to change from something identical to C declaration syntax, which is second nature for a great many people, to something that looks deceptively like C syntax but isn't.
I can't see that causing anything other than a massive amount of confusion, anguish and hair-tearing.
I would echo this, actually. While the C declarator syntax takes a while to get used to, there is actually a simple rationale for why it is the way it is: just one set of operator associativity and precedences. The way [], *, and function call ()s bind do not vary by context. One doesn't have to remember multiple sets of rules "tailored" for various contexts like declaration/typedef definition or casting vs operator application. I believe this is the "fact underlying" the reactions various folk here are having of "initially seemingly clearer, but oh wait..what about corner case?" There is a simplicity embedded in the seemingly backwards "operators you need to apply to get the base type" rule. The manual translation of C headers/decls to Cython is another good point. I think that it's a big departure from the perhaps hard to articulate "sweet spot" Cython/Pyrex are trying to hit straddling the C & Python worlds. Stefan Behnel wrote:
Also, C is only second nature to some people. A great many people actually use Cython specifically to *avoid* having to write C.
This is a fair point, but Pyrex/Cython have a decade plus long history here of being very close to C in this specific way, which is kind of a central thing..almost like a different way to spell the same type grammar. It's easy after a short while to visually see the translation. With whole new syntax and maybe parens in new, shiner places, I doubt seeing the mapping would be so easy for "hard cases". And easy cases are easy. On a separate relase-number-tying note, I also feel like the Cython 1.0 target (or even Pyrex 1.0) was always more about compatibility with "whatever Python you throw at the Cython compiler" than about finality to all the various extended Cython syntax areas. There are quite a few beyond-Py syntax areas at this point. So, *if* the conclusion is that there is a group will and solid rationale to let Cython allow a user to use an *alternate* type declaration sub-language/warnings/a wrapper/macro syntax, then I don't see any 1.0-release relevance. Cython grows just yet another way to specify the same things at whatever rev is easy. The 1.0 only matters if it's a strict backward incompatible proposal, but I sense a bit of discord on this response chain about that. Maybe changing "cdef" to be "cydef" would be a visual flag that an entirely different syntax is afoot? But then..sooo many ways to specify types. If you really want to be *that* different - arguably almost as much as different as simply requiring Python3 and annotations rather than having "cdef" at all, then why not go all the way and full on require Py3? Then a user confronts all the Py3 core syntax change and Cy2.0 (or maybe Cy1.5 as 3.0/2 or whatever) at the same time. And, why, the changes are even related to only-in-Py3 things to boot. Just my two cents, anyway. cb
On Thu, Oct 3, 2013 at 9:30 AM, Chuck Blake <cb@mit.edu> wrote:
Greg Ewing wrote:
What would be the benefit of this? You're proposing to change from something identical to C declaration syntax, which is second nature for a great many people, to something that looks deceptively like C syntax but isn't.
I can't see that causing anything other than a massive amount of confusion, anguish and hair-tearing.
I would echo this, actually.
The big win is a simplification of the grammar (and its diff to the Python grammar), both for humans and for the computer. Just being able to write an actual grammar for Cython would be nice--there's too much special casing/logic in the parser right now.
While the C declarator syntax takes a while to get used to, there is actually a simple rationale for why it is the way it is: just one set of operator associativity and precedences. The way [], *, and function call ()s bind do not vary by context. One doesn't have to remember multiple sets of rules "tailored" for various contexts like declaration/typedef definition or casting vs operator application.
I don't think this proposal would require multiple sets of rules for different contexts.
I believe this is the "fact underlying" the reactions various folk here are having of "initially seemingly clearer, but oh wait..what about corner case?" There is a simplicity embedded in the seemingly backwards "operators you need to apply to get the base type" rule.
While I understand the reasoning and construction of C type declarators, I don't think it makes for clear code. Note that Cython/Pyrex does not have the deference operator which is by far the most common declarator annotation, so this makes even less sense than in C. Of course trying to find/flesh out any forgotten corner cases is a big point of this thread. Function pointers still need to be resolved.
The manual translation of C headers/decls to Cython is another good point. I think that it's a big departure from the perhaps hard to articulate "sweet spot" Cython/Pyrex are trying to hit straddling the C & Python worlds.
Stefan Behnel wrote:
Also, C is only second nature to some people. A great many people actually use Cython specifically to *avoid* having to write C.
This is a fair point, but Pyrex/Cython have a decade plus long history here of being very close to C in this specific way, which is kind of a central thing..almost like a different way to spell the same type grammar. It's easy after a short while to visually see the translation. With whole new syntax and maybe parens in new, shiner places, I doubt seeing the mapping would be so easy for "hard cases". And easy cases are easy.
On a separate relase-number-tying note, I also feel like the Cython 1.0 target (or even Pyrex 1.0) was always more about compatibility with "whatever Python you throw at the Cython compiler" than about finality to all the various extended Cython syntax areas. There are quite a few beyond-Py syntax areas at this point.
Yes, it still is. But it would be nice to get any such major changes out of the way ahead of time.
So, *if* the conclusion is that there is a group will and solid rationale to let Cython allow a user to use an *alternate* type declaration sub-language/warnings/a wrapper/macro syntax, then I don't see any 1.0-release relevance. Cython grows just yet another way to specify the same things at whatever rev is easy. The 1.0 only matters if it's a strict backward incompatible proposal, but I sense a bit of discord on this response chain about that. Maybe changing "cdef" to be "cydef" would be a visual flag that an entirely different syntax is afoot? But then..sooo many ways to specify types.
That doesn't help with the goal of simplifying the language.
If you really want to be *that* different - arguably almost as much as different as simply requiring Python3 and annotations rather than having "cdef" at all, then why not go all the way and full on require Py3? Then a user confronts all the Py3 core syntax change and Cy2.0 (or maybe Cy1.5 as 3.0/2 or whatever) at the same time. And, why, the changes are even related to only-in-Py3 things to boot. Just my two cents, anyway.
Python2 isn't dead yet. Also, I think changes are more easily done one-at-a-time, and this would be an easier transition as it's a purely syntactic (not semantic) change that could be done safely automatically. In fact, if we dissallow "cdef int* a, b" I think there's syntax that's interpreted differently. - Robert
Robert Bradshaw [robertwb@gmail.com] wrote:
Yes, it still is. But it would be nice to get any such major changes out of the way ahead of time.
I think the "compiling Python" goal is so orthogonal to the goal of how "beyond Python syntax work" or simplicity of the parsing impl that "getting it out of the way" doesn't feel right. It's not like SciPy and a lot of other things don't have dependencies on lots of Cython code.
I don't think this proposal would require multiple sets of rules for different contexts.
Yeah. Probably. I just was explaining what I thought the mechanism behind people's reactions. They're used to something..wrinkles and all, potential for abuse and all, and honestly in terms of the bugs like that char *a,b malloc example -- visual bug finding and all. Not always, but a lot of the times there is just "confusion jello". Squeeze one place and it just oozes around. Also, Cython hasn't been so much about creating new Python syntax or new C syntax, and I think that makes it more approachable. Part of the question afoot, at least in the thread, was whether the learning curve for the new "less unclear code" is "worth the shift". Whatever common cases you make easy, nothing will ever hope to be as "search the internet"-supported as the C way. Part of debugging is a habit, a list in your head, and this proposes a new such list implicitly. So, just to confirm, I think what you propose would mean that the ubiquitous C string list is written sometimes as char *argv[] will have to change in every declared function signature that Cython sees?
That doesn't help with the goal of simplifying the language.
Sure it doesn't. I said so, too. :) I'm not strongly advocating that. I don't mind how it is now. I prefer no change, but I understand this is not about pleasing me, specifically. So, I make arguments. ;-)
Python2 isn't dead yet. Also, I think changes are more easily done
Your idea to simplify the language is a half measure. If simplicity of the compiler/syntax and Py similarity is what is *really* important then why not hatch a full measure Py3 plan as a longer-term goal? How long-term? Why, as long-term a goal as Py2 being mostly irrelevant, whenever that happens. I don't get the need for it to be a pre-1.0 goal. If there's a practical Py2 compatibility requirement, then why not a practical Cy <= 0.2 requirement, too? Just a leeetle more of the former than the latter and so on. All this just feels like a hair splitting judgement call. That kind of judgement just generally feels more appropriate for a post-1.0 mode of onward and upward language evolution to me not some last few releases move. Why not finish (mostly) all that you started to do with semantics and compiling and harden that as a release first? Then evolve something as basic as how to declare types. If Greg is as against the idea as his initial reaction, it'd also be a big divergence from Pyrex that is more basic than than just a cpdef or None-Arg or etc. kind of way since it impacts all type annotation. Type annotation (or inference) is the heart of .pyx over .py anyway. Not that there aren't a lot of other syntax variations, but in a lot of cases you can kind of code to the least common denominator if you care, like C++ compatible C. This would break that for any types beyond the most simple. Well, maybe least common Pyrex/Cy is more broken that I know anyway - I haven't tried to do it in a while. Cheers, cb
On Thu, Oct 3, 2013 at 3:06 PM, Chuck Blake <cb@mit.edu> wrote:
Robert Bradshaw [robertwb@gmail.com] wrote:
Yes, it still is. But it would be nice to get any such major changes out of the way ahead of time.
I think the "compiling Python" goal is so orthogonal to the goal of how "beyond Python syntax work" or simplicity of the parsing impl that "getting it out of the way" doesn't feel right. It's not like SciPy and a lot of other things don't have dependencies on lots of Cython code.
What I don't want to do is release 1.0, then in 1.1 have a major, backwards incompatible change. In particular, though the blocker for 1.0 is compatibility, I think it is a time to think about what we want to stick with going forward, and it would also be nice if we could provide backwards compatibility through the entire 1.0 series. (Yes, the next release after 1.0 could be 2.0, but I'd rather avoid that too :)
I don't think this proposal would require multiple sets of rules for different contexts.
Yeah. Probably. I just was explaining what I thought the mechanism behind people's reactions. They're used to something..wrinkles and all, potential for abuse and all, and honestly in terms of the bugs like that char *a,b malloc example -- visual bug finding and all. Not always, but a lot of the times there is just "confusion jello". Squeeze one place and it just oozes around. Also, Cython hasn't been so much about creating new Python syntax or new C syntax, and I think that makes it more approachable.
Part of the question afoot, at least in the thread, was whether the learning curve for the new "less unclear code" is "worth the shift". Whatever common cases you make easy, nothing will ever hope to be as "search the internet"-supported as the C way. Part of debugging is a habit, a list in your head, and this proposes a new such list implicitly.
So, just to confirm, I think what you propose would mean that the ubiquitous C string list is written sometimes as char *argv[] will have to change in every declared function signature that Cython sees?
Yes, though I rarely see that anywhere but main methods (that don't occur in Cython). Certainly a survey would be made of how much code out there in the wild would have to change (implicitly favoring open-source projects) which could make the whole thing not worth it.
That doesn't help with the goal of simplifying the language.
Sure it doesn't. I said so, too. :) I'm not strongly advocating that. I don't mind how it is now. I prefer no change, but I understand this is not about pleasing me, specifically. So, I make arguments. ;-)
Python2 isn't dead yet. Also, I think changes are more easily done
Your idea to simplify the language is a half measure. If simplicity of the compiler/syntax and Py similarity is what is *really* important then why not hatch a full measure Py3 plan as a longer-term goal?
I'm not sure what you mean here, Py3 is supported, and there is a -3 mode for interpreting ambiguous syntax the 3 way rather than the 2.
How long-term? Why, as long-term a goal as Py2 being mostly irrelevant, whenever that happens. I don't get the need for it to be a pre-1.0 goal.
If there's a practical Py2 compatibility requirement, then why not a practical Cy <= 0.2 requirement, too? Just a leeetle more of the former than the latter and so on. All this just feels like a hair splitting judgement call. That kind of judgement just generally feels more appropriate for a post-1.0 mode of onward and upward language evolution to me not some last few releases move. Why not finish (mostly) all that you started to do with semantics and compiling and harden that as a release first? Then evolve something as basic as how to declare types.
If Greg is as against the idea as his initial reaction, it'd also be a big divergence from Pyrex that is more basic than than just a cpdef or None-Arg or etc. kind of way since it impacts all type annotation. Type annotation (or inference) is the heart of .pyx over .py anyway. Not that there aren't a lot of other syntax variations, but in a lot of cases you can kind of code to the least common denominator if you care, like C++ compatible C. This would break that for any types beyond the most simple. Well, maybe least common Pyrex/Cy is more broken that I know anyway - I haven't tried to do it in a while.
Thanks for your thoughts, there are clearly some good reasons to not make this kind of change as well. - Robert
participants (5)
-
Chuck Blake -
Greg Ewing -
Nathaniel Smith -
Robert Bradshaw -
Stefan Behnel