[Cython] Automatic C++ conversions

[Robert Bradshaw]

On Fri, Jun 29, 2012 at 4:06 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 30.06.2012 00:38:
>> I implemented
>>
>> std::string <=> bytes
>> std::map <=> dict
>> iterable => std::vector => list
>> iterable => std::list => list
>> iterable => std::set => set
>> 2-iterable => std::pair => 2-tuple
>
> Very cool.
>
>
>>> What about allowing list(<C++ iterator>) etc.? As long as the item type can
>>> be coerced at compile time, this should be doable:
>>>
>>> <C++ iterator> => Python iterator
>>>
>>> and it would even be easy to implement in Cython code using a generator
>>> function.
>>
>> The tricky part is memory management; one would have to make sure the
>> iterable is valid as long as the Python object is around (whereas its
>> usually bound to the lifetime of its container).
>
> Ok, that's a problem then. We won't normally have any control over the
> container. That makes for-in a much more interesting solution.
>
>
>> Even more useful, however, would be supporting the "for ... in" syntax
>> for C++ iterators, which I plan to implement soon if no one beats me
>> to it.
>
> Yes, that'll be a warmly appreciated feature, I guess. Please go ahead. :)
>
>
>>> The other direction (Python iterator => <C++ iterator>) would be
>>> trickier but could also be made to work when the C++ item type on the LHS
>>> of the assignment that triggers the coercion is known at compile time.
>>
>> Yes, this would be actually probably be easier.
>
> I'm not currently sure about the details, at least the memory management
> should be easy. But given that we have the container coercions now, this
> might be a feature of minor interest anyway.
>
>
>>> We might want to look for a way to make these coercions a "thing" in the
>>> code (maybe through a registry or dedicated class) rather than adding
>>> special casing code everywhere.
>>
>> Perhaps, but that's a rather vague idea with less immediate benefit.
>> The list of obvious cases to support turns out to be rather clear and
>> small. (We already have the from/to_py_function framework.)
>
> Right. From your code, it turned out to be substantially more local than I
> thought.

And kudos to Mark for templatized cython utility code so I didn't have
to re-implement all that iterating in C.

>>> I think a CEP would be a good way to specify the above coercions.
>>
>> Though user-extensibility would be a larger topic and certainly
>> deserve a CEP, though I'm not claiming we want to support it.
>>
>>> I also think that this is large enough a feature to openly ask for sponsorship.
>>
>> That depends on the CEP.
>
> I think we can continue to postpone this until we actually find a use case
> where it provides a substantial benefit over what we have now. Similar
> feature requests have come up several times in the past, but so far, we
> always got away without it.

100% agree with you here.

- Robert