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