cython-devel

Download

cython-devel@python.org

March 2020

4 participants
2 discussions

Auto-generation of wrapper types
by da-woods March 25, 2020

March 25, 2020

The process of wrapping a C struct or C++ class in an extension type often has the user doing a pretty mechanical duplication of attributes/functions that Cython already knows about. I'm looking at doing: cdef struct S: int a # etc. then `cython.autowrap[S]` would create an extension type that wraps S by value. All attributes convertible to/from a Python type gets a property (as well as any attribute that has an has an autowrap declared). For `cppclass` this would extend to member functions as well - this obviously gets more involved, but again the same basic rule applies of only including stuff with an obvious conversion. I wouldn't propose to deal with the C++ nightmare of "how to return an owned reference". The idea would be to copy by value or nothing. I'd also propose only minor customization via keyword arguments (for example the name of a cdef staticmethod constructor, the name of the "obj" field in the C++ class). The basic rule would be that if it doesn't do what you want then it's an extension type, so you can always inherit from it and define the missing bits. Obviously structs have already have an automatic conversion to/from dicts and some cppclasses have autoconversions too. This wouldn't aim to replace that - it'd just be an option that the user could explicitly ask for. I have a somewhat working prototype for the struct side. Obviously the real complications are on the C++ side, but I don't think it's hugely difficult providing you accept there's lots of stuff that can't be guessed and inheritance is the way round that. Does this sound reasonable/something that'd be accepted? Any other thoughts? David

4 8

Preparing the first alpha release of Cython 3.0
by Stefan Behnel March 25, 2020

March 25, 2020

Hi all, I'm curently preparing a first alpha release for Cython 3.0 (alpha 1). Please ping me on any open pull requests that you think are ready and should be included. Note that this is not the end of the journey – anything that's not included right now can still come in later, before the first beta. (That's later this year, before you ask.) There will definitely be at least one more alpha release before we get even there. So, please concentrate on changes for this release that have a potentially disruptive user impact, so that our users can start preparing their code and/or complain early in order to keep us from making The One Big Mistake of breaking their code. Thanks, Stefan

2 1