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 _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
