Right. Sorry, not sure what I was thinking. Instead of a staticmethod constructor, maybe it's more useful to have a keyword arg for the name of the generated extension class?
-----Original Message----- From: cython-devel <cython-devel-bounces+frank.schlimbach=intel....@python.org> On Behalf Of da-woods Sent: Friday, March 13, 2020 12:02 PM To: cython-devel@python.org Subject: Re: [Cython] Auto-generation of wrapper types (Sorry, originally replied just to Frank not to the list) If I understand you correctly it'd be something like: cdef class WrappingOfS(autowrap[S]): def new_method(self): # implementation i.e. if you want to do something the automation can't do then you just inherit. If I don't understand you correctly then please clarify... On 13/03/2020 09:56, Schlimbach, Frank wrote: > I like automatism, this one looks useful. > > How would you allow extending the Extension type with a new attribute or > method? I'd expect that in many cases you need to do more than just wrapping > the C class/struct. > > -----Original Message----- > From: cython-devel > <cython-devel-bounces+frank.schlimbach=intel....@python.org> On Behalf > Of da-woods > Sent: Thursday, March 12, 2020 4:12 PM > To: cython-devel@python.org > Subject: [Cython] Auto-generation of wrapper types > > 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 > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of > the Supervisory Board: Nicole Lau Registered Office: Munich Commercial > Register: Amtsgericht Muenchen HRB 186928 > _______________________________________________ > 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 Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
