On Fri, Jun 29, 2012 at 4:06 PM, Stefan Behnel <stefan...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
