[Cython] How best to contribute
Hi. I would like to start contributing in a meaningful way to Cython on the order of ~1 day a week, within the framework of the time allocated to me from my employer (Quansight Labs) toward open source contributions. Over time, my goal is push for an HPy[0] backend for Cython, but I also want to help the project move forward toward an official 3.0 release and in general to help out where needed. So working backwards: What are the immediate pain points that I could help out with in general? How can I help with the 3.0 release (there are issues marked as "blockers", are all of them truly critical)? And, in the long term, is there a way to start designing a new backend for HPy? I would also like to suggest that Cython hold monthly open "developer calls" where people can meet face-to-face (on zoom) to work out priorities and triage particularly difficult issues or PRs. I would be happy to try to set this up (mainly to negotiate a time that would work) if you-all think it is a good idea and would contribute more than it would distract. Thanks, Matti [0] HPy [https://hpy.readthedocs.io/en/latest] ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [ENH] Compile-time code execution (macros / templates)
Greg, I assume the ast returned by twice will have the AST from f embedded in there somehow so no closure required. Something like: cdef _tmp_foo(...): # same as foo... cdef foo(...): _tmp_foo() _tmp_foo() -- PG ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [ENH] Compile-time code execution (macros / templates)
Prakhar Goel,
> Doesn't this just punt on how CdefFunction works? Feels like we're
> back to AST re-writing.
Indeed, internally it rewrites the AST, of course. I think that's the
simplest way to implement it. But it doesn't mean the user that write
the compile-time code would have to be aware of the AST at all.
I mean, if you have a good use-case for it, then I'm ok with allowing
the compile-time code manipulating it. But I'd really prefer this not be
the main use of the compile-time execution feature.
Greg Ewing,
> On 26/02/21 3:21 pm, Celelibi wrote:
> > def twice(f):
> > fun = CdefFunction(... use f ...)
> > return fun
> >
> > foo = CdefFunction(...)
> > ast.append(AstCdefFunction("foo", twice(foo)))
> >
> > I think this might even be doable without having to even detect the
> > closure in cython. We'd just have to let python perform the name lookup.
>
> The cdef function created inside twice() is going to have
> to be some kind of closure, because it needs access at run
> time to the particular f that was passed to twice() at
> compile time.
Yes, conceptually it's a closure. But not implemented as one.
Since the object `fun` (whose type is CdefFunction) is *not* a function,
it is not a closure in the usual sens. It's just some python object
having a reference to another object.
The only new feature might be to declare at the top-level the functions
that are referenced by the CdefFunction object that reach the top-level.
In short, the apparent closures are resolved during the compile-time
execution.
As Prakhar Goel pointed out, the AST of `fun` would hold a reference to
the AST of `foo`. The compile-time execution of the `twice` example
would produce an AST similar to that we would get by parsing the
following code.
cdef _unique_name_for_original_foo(x):
# Something math-y
cdef foo(x):
return _unique_name_for_original_foo(2*x)
Honestly, I would love to make a prototype as think there's really no
major obstacle, yet many seem to think there is.
Unfortunately, I don't think I'll have enough time until at least
several weeks.
Best regards,
Celelibi
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [ENH] Compile-time code execution (macros / templates)
> Indeed, internally it rewrites the AST, of course. I think that's the > simplest way to implement it. But it doesn't mean the user that write > the compile-time code would have to be aware of the AST at all. > I mean, if you have a good use-case for it, then I'm ok with allowing > the compile-time code manipulating it. But I'd really prefer this not be > the main use of the compile-time execution feature. Ah. I see where you are coming from. Wouldn't this be a ridiculous amount of work? At least if we insisted on something with a clean mental model that wouldn't just shred the user with a thousand corner cases? It would need a whole new sub-syntax in Cython with detailed semantics for all the weird things code lets people do (e.g. what if the input function f gets used like a first-class object and placed in a Python list that then gets passed to another function... at compile time...). You're basically asking for scheme's syntax-case but harder because Python/Cython are nowhere near as regular! And scheme's syntax-case is a beast (read up on phase separation if you don't believe me: https://docs.racket-lang.org/guide/phases.html). AST manipulation isn't _that_ hard (esp. with good helper libraries) and on the plus side, the basic idea is dead-simple to implement: just call some random Python function that the user points you towards. There's going to be some scaffolding but of an entirely manageable amount. I mean... if you think "there's really no major obstacle" then more power to you! I'd love to see what you come up with. But I think you're underestimating the complexity of the task. -- Warm Regards Prakhar Goel ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
