Kay Hayen wrote:
> Hello Dag,
>
> > [...] We also have
>
>> a mode using Python decorators to provide types ("pure Python" mode of
>> Cython).
>>
>
> Ah, that's very interesting. At the time I used Cython (I still have the
> 0.10.3 release somewhere), this was not present. So clearly, I will
> study the Cython docs and try to use that syntax instead.
>
See http://wiki.cython.org/pure
It's not as developed as we'd like it to be, but at least it is a proof
that we have the same aims that you have :-) And any help in this area
in general is very much appreciated; it wouldn't need to be using the
current syntax if something else is much better.
Haoyu Bai is currently doing a GSoC which may introduce Python 3
annotations as well:
def f(x: cython.int) -> cython.int:
...
> Being Python is so important for pylint, pychecker and most importantly
> flymake mode to work well. When I first encountered and used PyRex many
> years ago, that was immediately the problem with it.
>
> Also at the time the Cython project was very hesitant to make bigger
> changes, because it was following PyRex where possible. I wanted to e.g.
> change nodes and reference counting, so that generated code would be
> more local, and had written (to be generated) C code to back it up.
>
> Potentially PyRex similarity is no longer as important as it once was to
> the project as well.
>
Pyrex compatibility is much less important than it was, though we of
course want as much backwards compatibility as possible with older
Cython versions, which automatically means not breaking too much of the
Pyrex syntax. But, as you see we're happy for *additional* syntax in a
pure Python mode, and then we don't need to care about Pyrex at all.
The source code bases has diverged a lot, one cannot take patches from
Pyrex and apply on the Cython tree any longer.
> My main motivating factor for rolling my own stuff was to have a toy
> where one could more easily demonstrate the usefulness or not of things,
> in the first place. Then I can try and integrate it into Cython, which
> will have the actual community behind it.
>
> But as I said, it will be merely "correct" code generated. It won't be
> actually better code yet. But it will e.g. demonstrate a way to easily
> handle generator expressions and functions, something I believe Cython
> still doesn't do?
>
Closures (inner functions) are present in the next release (0.13).
Generator expressions are expected to land sometimes in the next half
year to a year, I think, though always take such estimates with a grain
of salt.
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
