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. >> 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. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
