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
