Re: Porting the 2-3 heap data-structure library from C to Python
Alec Taylor, 07.03.2012 15:25: > I am planning to port the 2-3 heap data-structure as described by > Professor Tadao Takaoka in Theory of 2-3 Heaps published in 1999 and > available in PDF: > http://www.cosc.canterbury.ac.nz/tad.takaoka/2-3heaps.pdf > > The source-code used has been made available: > http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.h > http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.c > > I plan on wrapping it in a class. > > This tutorial I used to just test out calling C within Python > (http://richizo.wordpress.com/2009/01/25/calling-c-functions-inside-python/) > and it seems to work, but this might not be the recommended method. > > Any best practices for how best to wrap the 2-3 heap data-structure > from C to Python? For data structures, where performance tends to matter, it's usually best to start with Cython right away, instead of using ctypes. http://cython.org/ Here's a tutorial for wrapping a C library with it: http://docs.cython.org/src/tutorial/clibraries.html Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting the 2-3 heap data-structure library from C to Python
Alec Taylor writes: > The source-code used has been made available: > http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.h > http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.c > > I plan on wrapping it in a class. You should get acquainted with the Python/C API, which is the standard way of extending Python with high-performance (and/or system-specific) C code. See "Extending and Embedding" and "Python/C API" sections at http://docs.python.org/. There is also a mailing list for help with the C API, see http://mail.python.org/mailman/listinfo/capi-sig for details. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting the 2-3 heap data-structure library from C to Python
Hrvoje Niksic, 07.03.2012 16:48: > Alec Taylor writes: > >> The source-code used has been made available: >> http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.h >> http://www.cosc.canterbury.ac.nz/research/RG/alg/ttheap.c >> >> I plan on wrapping it in a class. > > You should get acquainted with the Python/C API If it proves necessary, yes. > which is the standard way of extending Python with high-performance > (and/or system-specific) C code. Well, it's *one* way. Certainly not the easiest way, neither the most portable and you'll have a hard time making it the fastest. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting the 2-3 heap data-structure library from C to Python
Stefan Behnel writes: >> which is the standard way of extending Python with high-performance >> (and/or system-specific) C code. > > Well, it's *one* way. Certainly not the easiest way, neither the most > portable and you'll have a hard time making it the fastest. I didn't say it was easy, but standard, in the sense of documented in Python documentation. Python/C is as portable as Python itself, and as fast as the platform allows. I understand your desire to promote Cython, but please stop resorting to FUD in doing so. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting the 2-3 heap data-structure library from C to Python
On 3/10/2012 8:03 PM, Hrvoje Niksic wrote: Stefan Behnel writes: which is the standard way of extending Python with high-performance (and/or system-specific) C code. Well, it's *one* way. Certainly not the easiest way, neither the most portable and you'll have a hard time making it the fastest. I didn't say it was easy, but standard, in the sense of documented in Python documentation. Python/C is as portable as Python itself, and as Python is portable because a *lot* of work has gone and continues to go into making it so. And because it sticks with the lowest common denominator of C89. There is much system or compiler specific code in #ifdefs. There are over 60 buildbots for testing patches on various hardware-os-compiler-(python)version combinations. Perhaps once a week something does not work on one of them. The patch gets revised. It happened just today. Apple is changing compilers for the Mac; Python initially did not build with the new compiler. Some people had to do some work so there would continue to be Python on the Mac. So I can imagine that Cython *might* shield one from some of the very real portability problems. fast as the platform allows. I understand your desire to promote Cython, but please stop resorting to FUD in doing so. You admitted it might be easier. Portability is plausible. So I think that a bit harsh. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting the 2-3 heap data-structure library from C to Python
Hrvoje Niksic, 11.03.2012 02:03: > Stefan Behnel writes: >>> which is the standard way of extending Python with high-performance >>> (and/or system-specific) C code. >> >> Well, it's *one* way. Certainly not the easiest way, neither the most >> portable and you'll have a hard time making it the fastest. > > I didn't say it was easy, but standard, in the sense of documented in > Python documentation. Python/C is as portable as Python itself, and as > fast as the platform allows. Only if you know how to do it right and have the discipline to do a lot of cross-platform testing, benchmarking and tuning. Not everyone wants to invest that much time into details that are unrelated to the problem at hand. And why should they, when other people (who have gained some experience in it) have already done if for them and continue to do that, so that they don't need to care and can get it for free? > I understand your desire to promote > Cython, but please stop resorting to FUD in doing so. I can't see it being FUD (although arguably promotion) to tell people that "we write C so you don't have to". It's certainly not FUD that it's easier (and IMHO also more fun) to write good Python code than good C code. Quite the contrary, telling new users to go straight for writing C code and using CPython's C-API natively is like asking them why (the heck!) they are using Python in the first place, when they can just dive into the beautiful world of C. I don't think that's the ideal attitude for this list. Stefan -- http://mail.python.org/mailman/listinfo/python-list