On Thu, Oct 3, 2013 at 3:06 PM, Chuck Blake <c...@mit.edu> wrote: > 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.
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 _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
