Porting the 2-3 heap data-structure library from C to Python

[Alec Taylor]

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?

Thanks for all suggestions,

Alec Taylor

 

[Hrvoje Niksic]

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.

 

[Stefan Behnel]

Hrvoje Niksic, 07.03.2012 16:48:

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

 

[Hrvoje Niksic]

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.

 

[Terry Reedy]

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.

 

[Stefan Behnel]

Hrvoje Niksic, 11.03.2012 02:03:

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