[Cython] Exposing C++'s
Hello, I was wanting to use C++s' back_inserter in Cython, and I got it working. I'm writing the list to ask about what more I should do before submitting a pull request. In short, the following definitions were sufficient: ##Define the basic iterator types (this is incomplete) cdef extern from "" namespace "std": cdef cppclass iterator[Category,T,Distance,Pointer,Reference]: pass cdef cppclass output_iterator_tag: pass #The goal here is to get back_inserter working, as it is handy. cdef cppclass back_insert_iterator[T](iterator[output_iterator_tag,void,void,void,void]): pass back_insert_iterator[CONTAINER] back_inserter[CONTAINER](CONTAINER &) ##Not shown here, but I've gotten C++11's move algorithm to work, too, ##using same kind of prototype cdef extern from "" namespace "std": OUTPUT copy[INPUT,OUTPUT](INPUT,INPUT,OUTPUT) I've worked up a tiny test package that is on GitHub: https://github.com/molpopgen/cython_cpp_iterators The tests work, and I can indeed copy amongst C++ containers. I've also gotten the C++ move algorithm to work. The prototype is the same as for 'copy' above. I'd be willing to define the remaining classes from and add a .pxd file. Any input would be appreciated. Thanks, Kevin ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] C++ structs, namespace, and auto-conversion of struct to dict
Hi, I recently ran into an issue where I found that Cython will not generate code to auto-convert structs do dicts if the struct is declared in a C++ namespace. The issue has also been discussed here: http://stackoverflow.com/questions/29603562/auto-conversion-of-structs-to-dicts-in-cython While there are obvious workarounds, none of them are ideal. Is there a road map for addressing this issue? If not, what would it take to do so, and where in the code should one start looking? Thanks, Kevin ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.23.4: Crash with Template Stuff
Without knowing more about the "blitz" stuff, it is hard to provide detailed help. However, it looks like you have a template taking a non-typename as a parameter, which is not currently supported in Cython. In other words, the 1 in [double,1] is not a type name, and that causes Cython to give up. There is a pull request in progress to fix this issue on GitHub, but I'm not sure what the latest is on that. On Sun, Jan 31, 2016 at 11:07 PM Elizabeth Fischer wrote: > Cython is crashing on me when I compile. See below. > > -- Elizabeth > > cython --version > > Cython version 0.23.4 > > Error compiling Cython file: > > ... > #cdef int flags > > def test_double_blitz(a): > cdef vector[int] v > cdef cblitz.Array[double,1] a_b > a_b = cibmisc.np_to_blitz[double,1](a, b'var', [-1]) > ^ > > > /Users/rpfische/git/ibmisc/pylib/ibmisc.pyx:38:26: Compiler crash in > AnalyseExpressionsTransform > > ModuleNode.body = StatListNode(ibmisc.pyx:1:0) > StatListNode.stats[3] = StatListNode(ibmisc.pyx:35:0) > StatListNode.stats[0] = DefNode(ibmisc.pyx:35:0, > modifiers = [...]/0, > name = 'test_double_blitz', > num_required_args = 1, > py_wrapper_required = True, > reqd_kw_flags_cname = '0', > used = True) > File 'Nodes.py', line 430, in analyse_expressions: > StatListNode(ibmisc.pyx:36:1) > File 'Nodes.py', line 4775, in analyse_expressions: > SingleAssignmentNode(ibmisc.pyx:38:36) > File 'Nodes.py', line 4887, in analyse_types: > SingleAssignmentNode(ibmisc.pyx:38:36) > File 'ExprNodes.py', line 4640, in analyse_types: > SimpleCallNode(ibmisc.pyx:38:36, > analysed = True, > result_is_used = True, > use_managed_ref = True) > File 'ExprNodes.py', line 3109, in analyse_types: > IndexNode(ibmisc.pyx:38:26, > is_called = 1, > is_subscript = True, > result_is_used = True, > use_managed_ref = True) > File 'ExprNodes.py', line 3419, in analyse_base_and_index_types: > IndexNode(ibmisc.pyx:38:26, > is_called = 1, > is_subscript = True, > result_is_used = True, > use_managed_ref = True) > > Compiler crash traceback from this point on: > File > "/Users/rpfische/macports/mpgompi-4.9.3/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Compiler/ExprNodes.py", > line 3419, in analyse_base_and_index_types > elif len(base_type.templates) != len(self.type_indices): > TypeError: object of type 'NoneType' has no len() > make[2]: *** [pylib/ibmisc.cpp] Error 1 > make[2]: *** Deleting file `pylib/ibmisc.cpp' > make[1]: *** [pylib/CMakeFiles/ibmisc_so.dir/all] Error 2 > make: *** [all] Error 2 > > ___ > 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] Cython 0.23.4: Crash with Template Stuff
That'd be nice, but the main developers will have to weigh in on that. On Mon, Feb 1, 2016 at 21:14 Elizabeth Fischer wrote: > I think you've figured out what's going on. Short of adding the feature, > is it possible to add a better error message, rather than what looks like a > random crash? > > -- Elizabeth > > > > On Mon, Feb 1, 2016 at 8:08 PM, Kevin Thornton wrote: > >> Without knowing more about the "blitz" stuff, it is hard to provide >> detailed help. >> >> However, it looks like you have a template taking a non-typename as a >> parameter, which is not currently supported in Cython. >> >> In other words, the 1 in [double,1] is not a type name, and that causes >> Cython to give up. There is a pull request in progress to fix this issue >> on GitHub, but I'm not sure what the latest is on that. >> >> On Sun, Jan 31, 2016 at 11:07 PM Elizabeth Fischer >> wrote: >> >>> Cython is crashing on me when I compile. See below. >>> >>> -- Elizabeth >>> >>> cython --version >>> >>> Cython version 0.23.4 >>> >>> Error compiling Cython file: >>> >>> ... >>> #cdef int flags >>> >>> def test_double_blitz(a): >>> cdef vector[int] v >>> cdef cblitz.Array[double,1] a_b >>> a_b = cibmisc.np_to_blitz[double,1](a, b'var', [-1]) >>> ^ >>> >>> >>> /Users/rpfische/git/ibmisc/pylib/ibmisc.pyx:38:26: Compiler crash in >>> AnalyseExpressionsTransform >>> >>> ModuleNode.body = StatListNode(ibmisc.pyx:1:0) >>> StatListNode.stats[3] = StatListNode(ibmisc.pyx:35:0) >>> StatListNode.stats[0] = DefNode(ibmisc.pyx:35:0, >>> modifiers = [...]/0, >>> name = 'test_double_blitz', >>> num_required_args = 1, >>> py_wrapper_required = True, >>> reqd_kw_flags_cname = '0', >>> used = True) >>> File 'Nodes.py', line 430, in analyse_expressions: >>> StatListNode(ibmisc.pyx:36:1) >>> File 'Nodes.py', line 4775, in analyse_expressions: >>> SingleAssignmentNode(ibmisc.pyx:38:36) >>> File 'Nodes.py', line 4887, in analyse_types: >>> SingleAssignmentNode(ibmisc.pyx:38:36) >>> File 'ExprNodes.py', line 4640, in analyse_types: >>> SimpleCallNode(ibmisc.pyx:38:36, >>> analysed = True, >>> result_is_used = True, >>> use_managed_ref = True) >>> File 'ExprNodes.py', line 3109, in analyse_types: >>> IndexNode(ibmisc.pyx:38:26, >>> is_called = 1, >>> is_subscript = True, >>> result_is_used = True, >>> use_managed_ref = True) >>> File 'ExprNodes.py', line 3419, in analyse_base_and_index_types: >>> IndexNode(ibmisc.pyx:38:26, >>> is_called = 1, >>> is_subscript = True, >>> result_is_used = True, >>> use_managed_ref = True) >>> >>> Compiler crash traceback from this point on: >>> File >>> "/Users/rpfische/macports/mpgompi-4.9.3/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Compiler/ExprNodes.py", >>> line 3419, in analyse_base_and_index_types >>> elif len(base_type.templates) != len(self.type_indices): >>> TypeError: object of type 'NoneType' has no len() >>> make[2]: *** [pylib/ibmisc.cpp] Error 1 >>> make[2]: *** Deleting file `pylib/ibmisc.cpp' >>> make[1]: *** [pylib/CMakeFiles/ibmisc_so.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> ___ >>> 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 >> >> > ___ > 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] C++ structs, namespace, and auto-conversion of struct to dict
Great--thanks! On Tue, Feb 2, 2016 at 12:56 AM Robert Bradshaw wrote: > On Mon, Feb 1, 2016 at 5:03 PM, Kevin Thornton wrote: > > Hi, > > > > I recently ran into an issue where I found that Cython will not generate > > code to auto-convert structs do dicts if the struct is declared in a C++ > > namespace. > > > > The issue has also been discussed here: > > > http://stackoverflow.com/questions/29603562/auto-conversion-of-structs-to-dicts-in-cython > > > > While there are obvious workarounds, none of them are ideal. > > > > Is there a road map for addressing this issue? > > I simply didn't know about it. > > > If not, what would it take > > to do so, and where in the code should one start looking? > > > https://github.com/cython/cython/commit/fa946e8435a4dcc3497fc7b0f4e87256d40844ba > ___ > 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
[Cython] Cython 0.23.4 bug: C++ pairs with unsigned values inside other templates
Hi, I've come across an odd bug while creating interfaces to existing C++ functions via Cython. If a C++ pair is contained inside of another template type, the pair cannot contain unsigned integers unless a typedef is provided for unsigned. Examples: #This works: cdef vector[pair[char,char]] doit(): cdef vector[pair[char,char]] rv return rv #This fails: cdef vector[pair[unsigned,char]] doit2(): cdef vector[pair[unsigned,char]] rv return rv #But this works: ctypedef unsigned uint cdef vector[pair[uint,uint]] doit3(): cdef vector[pair[uint,uint]] rv return rv #This fails: cdef void doit4( const vector[pair[unsigned,double]] & x): pass --Kevin ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython alpha 0.24
Hi, I just built a large project with the alpha version. All looks good. The only new/odd thing is a lot of warnings of this flavor: warning: View.MemoryView:219:4: 'property memview:' syntax is deprecated, use '@property' warning: View.MemoryView:536:4: 'property T:' syntax is deprecated, use '@property' warning: View.MemoryView:543:4: 'property base:' syntax is deprecated, use '@property' warning: View.MemoryView:548:4: 'property shape:' syntax is deprecated, use '@property' warning: View.MemoryView:553:4: 'property strides:' syntax is deprecated, use '@property' warning: View.MemoryView:562:4: 'property suboffsets:' syntax is deprecated, use '@property' warning: View.MemoryView:570:4: 'property ndim:' syntax is deprecated, use '@property' warning: View.MemoryView:575:4: 'property itemsize:' syntax is deprecated, use '@property' warning: View.MemoryView:580:4: 'property nbytes:' syntax is deprecated, use '@property' warning: View.MemoryView:585:4: 'property size:' syntax is deprecated, use '@property' warning: View.MemoryView:984:4: 'property base:' syntax is deprecated, use '@property' warning: View.MemoryView:219:4: 'property memview:' syntax is deprecated, use '@property' warning: View.MemoryView:536:4: 'property T:' syntax is deprecated, use '@property' warning: View.MemoryView:543:4: 'property base:' syntax is deprecated, use '@property' warning: View.MemoryView:548:4: 'property shape:' syntax is deprecated, use '@property' warning: View.MemoryView:553:4: 'property strides:' syntax is deprecated, use '@property' warning: View.MemoryView:562:4: 'property suboffsets:' syntax is deprecated, use '@property' warning: View.MemoryView:570:4: 'property ndim:' syntax is deprecated, use '@property' warning: View.MemoryView:575:4: 'property itemsize:' syntax is deprecated, use '@property' warning: View.MemoryView:580:4: 'property nbytes:' syntax is deprecated, use '@property' --Kevin On Fri, Mar 11, 2016 at 12:26 AM Robert Bradshaw wrote: > We are getting ready to push a new major release. A first alpha is up > at http://cython.org/release/Cython-0.24a0.tar.gz > > To avoid surprises, please test and report. > > Thanks, > Robert > ___ > 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] RFC: an inline_ function that dumps c/c++ code to the code emitter
Hi Robert, Related to this point, I think there are three important features that Cython would benefit from, as far as C++11 and newer are concerned. In order of what I'm guessing to be increased complexity are: 1. Non-type template parameters. 2. "rvalue" references for standalone functions and class member functions: void foo[T]( T && t ) 3. Variadic templates (member and non-member). More generally, "parameter packs": http://en.cppreference.com/w/cpp/language/parameter_pack #2 is important for efficiency reasons--it isn't just a convenience feature. Without it, Cython cannot support all the member function of std::vector, etc. The implication is that some expensive operations, like moving a big object into a vector, require extra copies in Cython while a C++ program would just move the object into the new location. #3 seems like the hardest, but would enable std::tuple, std::bind, and other handy things to be used in a .pyx file. Support for "auto" would be nice, but perhaps unrealistic. I know that PRs have been submitted, and since stalled out, on a couple of these features. I've tried to look at the Cython parser myself, but I'm not able to follow it, sadly. Thanks for all your hard work, Kevin On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw wrote: > > Though, as you discovered, there are some basic things like non-type > template arguments that we would like to have. If there are other > specific C++ constructs that are commonly used but impossible to > express in Cython it'd be useful to know. > > > ___ > 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] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Sat, Aug 20, 2016 at 11:15 PM Robert Bradshaw wrote: > On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton wrote: > > Hi Robert, > > > > Related to this point, I think there are three important features that > > Cython would benefit from, as far as C++11 and newer are concerned. In > > order of what I'm guessing to be increased complexity are: > > > > 1. Non-type template parameters. > > This is actually probably the hardest :). There is a PR that's stalled > out, probably needs some attention by both the author and us; it'd be > great to get this in. > > > 2. "rvalue" references for standalone functions and class member > functions: > > > > void foo[T]( T && t ) > > From a callers perspective, one can just declare an extern foo as > foo(T) in Cython, it doesn't care if the actual call is made by value > or by reference--the calling code is exactly the same. > > Actually implementing it for Cython-defined functions (as the callee) > would require additional support, but would probably be pretty easy > (implement a new type, with parsing, which generally behaves the same > as a reference or value from Python's perspective--the actual heavy > lifting happens in the C compiler). > > Want to file an issue on github for this? > Sure--will do. > > > 3. Variadic templates (member and non-member). More generally, > "parameter > > packs": > > > > http://en.cppreference.com/w/cpp/language/parameter_pack > > This'd be interesting (especially as to how it relates to changing the > arity of functions for concrete instantiations). There's also a > question of syntax. Maybe > > void foo[A, int N, ... Types](A a, Types t): > ... > > It'd likely require #1, e.g. to be able to declare things like > tuple_element::type such that std::tuple.get would be correctly > typed. Unfortunately seems declaring the (somewhat intuitive) API of > std::tuple requires being able to declare a fair amount of its > implementation. > > Still likely feasible though, and I think the notion of variadic > templates is natural enough in a Python setting (which has had > heterogeneously typed tuples since its inception, though of course not > statically typed). > > > #2 is important for efficiency reasons--it isn't just a convenience > feature. > > Without it, Cython cannot support all the member function of std::vector, > > etc. The implication is that some expensive operations, like moving a > big > > object into a vector, require extra copies in Cython while a C++ program > > would just move the object into the new location. > > It's interesting to call this an essential feature, given that C++ > itself didn't have it until recently :). Not that it can't be a big > win, and libraries will more and more probably be designed assuming > it. > Also, libraries not designed assuming it can still take advantage of it in many contexts. For lots of objects, the move constructor can be implicitly created by the constructor. Also, this would solve some quirks for Cython. Right now, std::unique_ptr is supported, but the object is non-copyable. One needs std::move in order to have this type be fully-functional. > > #3 seems like the hardest, but would enable std::tuple, std::bind, and > other > > handy things to be used in a .pyx file. > > > > Support for "auto" would be nice, but perhaps unrealistic. > > Just leave the cdef out and you basically get auto, i.e. > > my_var = expr > > gives my_var the type of expr. If multiple assignments are made to > my_var, it attempts to find a suitable union type that can hold all > assignments. The one exception is for integers, where it infers the > type to be object iff my_var is used in arithmetic expressions (that > it can't deduce would not overflow with the finite-sized C integer > type). > This is surprising to me. Would my_var be passable to a "cdef nogil" function? I'll have to give this a try--thanks for the tip! > > > I know that PRs have been submitted, and since stalled out, on a couple > of > > these features. I've tried to look at the Cython parser myself, but I'm > not > > able to follow it, sadly. > > > > Thanks for all your hard work, > > > > Kevin > > > > On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw > wrote: > >> > >> > >> Though, as you discovered, there are some basic things like non-type > >> template arguments that we would like to have. If there are other > >> specific C++ construct
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Sat, Aug 20, 2016 at 11:15 PM Robert Bradshaw wrote: > On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton wrote: > > Hi Robert, > > > > Related to this point, I think there are three important features that > > Cython would benefit from, as far as C++11 and newer are concerned. In > > order of what I'm guessing to be increased complexity are: > > > > 1. Non-type template parameters. > > This is actually probably the hardest :). There is a PR that's stalled > out, probably needs some attention by both the author and us; it'd be > great to get this in. > > > 2. "rvalue" references for standalone functions and class member > functions: > > > > void foo[T]( T && t ) > > From a callers perspective, one can just declare an extern foo as > foo(T) in Cython, it doesn't care if the actual call is made by value > or by reference--the calling code is exactly the same. > > Actually implementing it for Cython-defined functions (as the callee) > would require additional support, but would probably be pretty easy > (implement a new type, with parsing, which generally behaves the same > as a reference or value from Python's perspective--the actual heavy > lifting happens in the C compiler). > > Want to file an issue on github for this? > > > 3. Variadic templates (member and non-member). More generally, > "parameter > > packs": > > > > http://en.cppreference.com/w/cpp/language/parameter_pack > > This'd be interesting (especially as to how it relates to changing the > arity of functions for concrete instantiations). There's also a > question of syntax. Maybe > > void foo[A, int N, ... Types](A a, Types t): > ... > > It'd likely require #1, e.g. to be able to declare things like > tuple_element::type such that std::tuple.get would be correctly > typed. Unfortunately seems declaring the (somewhat intuitive) API of > std::tuple requires being able to declare a fair amount of its > implementation. > > Still likely feasible though, and I think the notion of variadic > templates is natural enough in a Python setting (which has had > heterogeneously typed tuples since its inception, though of course not > statically typed). > > > #2 is important for efficiency reasons--it isn't just a convenience > feature. > > Without it, Cython cannot support all the member function of std::vector, > > etc. The implication is that some expensive operations, like moving a > big > > object into a vector, require extra copies in Cython while a C++ program > > would just move the object into the new location. > > It's interesting to call this an essential feature, given that C++ > itself didn't have it until recently :). Not that it can't be a big > win, and libraries will more and more probably be designed assuming > it. > > > #3 seems like the hardest, but would enable std::tuple, std::bind, and > other > > handy things to be used in a .pyx file. > > > > Support for "auto" would be nice, but perhaps unrealistic. > > Just leave the cdef out and you basically get auto, i.e. > > my_var = expr > > gives my_var the type of expr. If multiple assignments are made to > my_var, it attempts to find a suitable union type that can hold all > assignments. The one exception is for integers, where it infers the > type to be object iff my_var is used in arithmetic expressions (that > it can't deduce would not overflow with the finite-sized C integer > type). > Wow--that does work (at least for simple cases). It may be nice to have a paragraph about this in the dox? Something like "Emulating auto in C++"? We've been doing a lot of copy/pasting of type names b/c we weren't aware of this. > > > I know that PRs have been submitted, and since stalled out, on a couple > of > > these features. I've tried to look at the Cython parser myself, but I'm > not > > able to follow it, sadly. > > > > Thanks for all your hard work, > > > > Kevin > > > > On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw > wrote: > >> > >> > >> Though, as you discovered, there are some basic things like non-type > >> template arguments that we would like to have. If there are other > >> specific C++ constructs that are commonly used but impossible to > >> express in Cython it'd be useful to know. > >> > >> > >> ___ > >> 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 > > > ___ > 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] RFC: an inline_ function that dumps c/c++ code to the code emitter
I actually just realized another nagging issue with C++/Cython: member typedefs are not supported: cdef vector[T]: ctypedef size_t size_type These "scoped" typedefs are very widely-used. We can live without it, and we have been, but while we're making a list.. :) --Kevin On Sat, Aug 20, 2016 at 11:15 PM Robert Bradshaw wrote: > On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton wrote: > > Hi Robert, > > > > Related to this point, I think there are three important features that > > Cython would benefit from, as far as C++11 and newer are concerned. In > > order of what I'm guessing to be increased complexity are: > > > > 1. Non-type template parameters. > > This is actually probably the hardest :). There is a PR that's stalled > out, probably needs some attention by both the author and us; it'd be > great to get this in. > > > 2. "rvalue" references for standalone functions and class member > functions: > > > > void foo[T]( T && t ) > > From a callers perspective, one can just declare an extern foo as > foo(T) in Cython, it doesn't care if the actual call is made by value > or by reference--the calling code is exactly the same. > > Actually implementing it for Cython-defined functions (as the callee) > would require additional support, but would probably be pretty easy > (implement a new type, with parsing, which generally behaves the same > as a reference or value from Python's perspective--the actual heavy > lifting happens in the C compiler). > > Want to file an issue on github for this? > > > 3. Variadic templates (member and non-member). More generally, > "parameter > > packs": > > > > http://en.cppreference.com/w/cpp/language/parameter_pack > > This'd be interesting (especially as to how it relates to changing the > arity of functions for concrete instantiations). There's also a > question of syntax. Maybe > > void foo[A, int N, ... Types](A a, Types t): > ... > > It'd likely require #1, e.g. to be able to declare things like > tuple_element::type such that std::tuple.get would be correctly > typed. Unfortunately seems declaring the (somewhat intuitive) API of > std::tuple requires being able to declare a fair amount of its > implementation. > > Still likely feasible though, and I think the notion of variadic > templates is natural enough in a Python setting (which has had > heterogeneously typed tuples since its inception, though of course not > statically typed). > > > #2 is important for efficiency reasons--it isn't just a convenience > feature. > > Without it, Cython cannot support all the member function of std::vector, > > etc. The implication is that some expensive operations, like moving a > big > > object into a vector, require extra copies in Cython while a C++ program > > would just move the object into the new location. > > It's interesting to call this an essential feature, given that C++ > itself didn't have it until recently :). Not that it can't be a big > win, and libraries will more and more probably be designed assuming > it. > > > #3 seems like the hardest, but would enable std::tuple, std::bind, and > other > > handy things to be used in a .pyx file. > > > > Support for "auto" would be nice, but perhaps unrealistic. > > Just leave the cdef out and you basically get auto, i.e. > > my_var = expr > > gives my_var the type of expr. If multiple assignments are made to > my_var, it attempts to find a suitable union type that can hold all > assignments. The one exception is for integers, where it infers the > type to be object iff my_var is used in arithmetic expressions (that > it can't deduce would not overflow with the finite-sized C integer > type). > > > I know that PRs have been submitted, and since stalled out, on a couple > of > > these features. I've tried to look at the Cython parser myself, but I'm > not > > able to follow it, sadly. > > > > Thanks for all your hard work, > > > > Kevin > > > > On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw > wrote: > >> > >> > >> Though, as you discovered, there are some basic things like non-type > >> template arguments that we would like to have. If there are other > >> specific C++ constructs that are commonly used but impossible to > >> express in Cython it'd be useful to know. > >> > >> > >> ___ > >> 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 > > > ___ > 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] Preparations for Cython 0.26.1 and 0.27
If you want to be pedantic, #1788 can be viewed as desirable. Thou shall not (publicly) inherit from namespace std's containers. On Wed, Aug 2, 2017 at 2:50 AM Stefan Behnel wrote: > Hi! > > Given the current set of bugs and regressions in 0.26, I think we should > start preparing a 0.26.1 release. I've already updated the release branch > with recent fixes. It's currently the same as master, but I'd like to > separate the branches soon in order to start merging features for 0.27 to > avoid bit-rot. > > The following regressions seem worth looking into for 0.26.1: > > https://github.com/cython/cython/issues/1790 > > https://github.com/cython/cython/issues/1788 > > Anything else of importance? > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > -- Kevin Thornton Associate Professor Ecology and Evolutionary Biology UC Irvine http://www.molpopgen.org http://github.com/ThorntonLab http://github.com/molpopgen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
