Re: [Cython] How best to contribute

2021-02-27 Thread da-woods

I'm tactically ignoring the bits of this I don't know the answer to:

> there are issues marked as "blockers", are all of them truly critical

I think the main criteria for being a "blocker" was to try to keep 
significant breaks in compatibility to the Cython 3 release (so that 
users might been to fix their code a little after Cython 3, but probably 
not after that). Thus https://github.com/cython/cython/issues/1159 is a 
"blocker" because people might be relying on the old behaviour. 
Personally I think most of the remaining blockers are probably small 
enough that maybe they shouldn't really block anything (but opinions may 
vary on this).


Of those blockers https://github.com/cython/cython/issues/2912 looks 
like something that could be fixed pretty quickly if you were inclined 
just by making a new PR based on the old one.


> And, in the long term, is there a way to start designing a new 
backend for HPy


I think the first question is: do you add HPy code to the existing .c 
file with extra include-guards, or do you want to make it a compiler 
option to either generate a PyObject* .c file or a HPy .c file? My 
opinion would be to make it a compiler option - I think doing it with 
include-guards would end up mixing in too much dissimilar code.


If you do want to generate a separate backend then we don't currently 
have anything similar. Maybe have a separate shadow sets of nodes and 
adding a transform just before the code generation step (so 
`ExprNodes.AttributeNode` is transformed into 
`ExprNodes.HPy.AttributeNode` which then handles the code generation, 
but doesn't need to include any of the analyse_types steps). My 
impression is that you can mix PyObject with HPy so you don't 
necessarily have to do everything in one go.


Having some "switchable backend" mechanism might turn out to be useful 
generally: there was also a request for "micropython" support a while 
back, which is realistically too different to be forced into the current 
PyObject code, but might be possible to support with switchable backends 
(if someone were inclined to do it).



David



On 26/02/2021 08:03, Matti Picus wrote:

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



___
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)

2021-02-27 Thread Celelibi
Le Fri, Feb 26, 2021 at 09:44:51PM -0500, Prakhar Goel a écrit :
> > 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).

Clearly, I think what I'm proposing has one of the simplest mental model
one could dream of. And if I'm not mistaken, it's not much work (I mean,
no fancy algorithms).
I mean, how could the mental model be any simpler than bringing in that
of python itself?

I don't know what example you had in mind, but I don't plan to have any
kind of static analysis in cython at all. All the burden is offloaded to
the python interpreter by running nothing but Pure Python Code. I'll
expand on that in a minute.

I mean, if you think you got an example that would be hard to analyze
with your list containing functions, then please expand on it. I'll
try my best to answer how my proposal would handle it. That's one of the
reasons I started this thread: to challenge the idea.

Here's how I see it working.
After some basic analysis, cython produces a python program that
basically rebuild the AST at that point and run the code itself at the
same time, with a few modifications.
1) cdef aren't run (of course, it's not python code), they're replaced
by the creation of a CdefFunction or CdefClass objects.
2) Functions marked ctfe_only aren't added to the AST.
3) Assignments maked with the `ctfe` keyword are handled specially to
turn whatever was returned to a new definition. (I can expand on that if
you want, especially on the "outlining" of functions.)

Running the code mostly means that all the def and assignment and
everything is evaluated. This has some obvious drawbacks, though.
Especially if it's a stadalone program, it would just... run. But this
is unavoidable. For instance the program could have conditional function
definition (a def in a if), that's used as compile time.
But I guess it's not much of an issue since a module would not have much
to run during load time, and a standalone program would be protected by
`if __name__ == "__main__":`.

> 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'm not saying AST manipulation is hard. I'm rather saying it's unusual
in python. And it's so low level it's rarely easy to understand what's
going.
As someone who reads a lot more code than I write, I use grep and other
such tools a lot. And I have to say I'm not really a big fan of that
kind of trickery. If a coding pattern would fool grep + a brain, other
analysis tools were lost eons ago.

But if you have an actual use case for AST manipulation that would
belong to a preprocessing phase, then please explain it to me.
The only time I had to deal with python AST (beside cython itself,
obviously), was to write an external analysis tool to help me migrate a
program from threads to asyncio. Not a valid use-case for my proposal.


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)

2021-02-27 Thread Prakhar Goel
I think we're past the point where more talking would help. Either I'm
missing something important or you are. Like I said, if you ever get
around to implementing this, drop me a line. I'd love to take a look.
--

Warm Regards
Prakhar Goel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel