[Cython] How best to contribute

da-woods dw-git at d-woods.co.uk
Sat Feb 27 07:44:07 EST 2021


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 at python.org
> https://mail.python.org/mailman/listinfo/cython-devel




More information about the cython-devel mailing list