Re: [Cython] Auto-generation of wrapper types
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 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
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 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
Re: [Cython] Auto-generation of wrapper types
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 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 > 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
Re: [Cython] Auto-generation of wrapper types
The staticmethod constructor is useful I think - regular constructors can't take C/C++ types so the static method constructor provides a means of doing something like: cdef mycppclass inst = # some call to cpp return wrapperclass.create(inst) I definitely agree you want some means of naming the generated class. At the minute I'm my thoughts are to do two things: 1. Having a cache of the generated classes (so autowrap[S] always returns the exact same class if you've already created one). That'd mean there's no penalty for just always referring to it as autowrap[S], so you don't /really/ need to name it. 2. Allow something like `ctypedef autowrap[S] whatever_name` (which doesn't currently look to work...) With that said, adding an option to override the name would be pretty easy, and probably useful. As always, it's a fine balance is always between making sure you have the useful options and ending up in a huge option overload so no-one can work out where to start. On 13/03/2020 11:29, Schlimbach, Frank wrote: 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 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 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
