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

Reply via email to