[Cython] Auto-generation of wrapper types

[da-woods]

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 <cython-devel-bounces+frank.schlimbach=intel.com at python.org> On Behalf Of da-woods
> Sent: Friday, March 13, 2020 12:02 PM
> To: cython-devel at 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.com at python.org> On Behalf
>> Of da-woods
>> Sent: Thursday, March 12, 2020 4:12 PM
>> To: cython-devel at 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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/cython-devel
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at 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 at python.org
> https://mail.python.org/mailman/listinfo/cython-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20200313/e1d51ecb/attachment.html>