Reasons to extend Python with C

[sneek]

Hello,

I've read the python doc (C-API) and was wondering about the two reasons to extend python with C. The first reason is to implement new build-in object types and the second one is to call C-Library functions and system calls.
Ok, I think i got the second one but what's about the new build-in objects? Does that mean that I am able to mix my written c-modules with the existing python source files and recompile the interpreter so I'm using static binding to create my "own/new" python-interpreter including my own types?
If I just use dynamic binding (e.g. using distutils to create a library and than "import myLib") I think I got the same behavior like writing a python class in a separate module file and use it afterwards. In both cases I will have new type.
Probably I don't understand what they want to tell me with build-in objects. May anybody help me with that? Thanks a lot.

Jonny

[Gribouillis]

There are many examples of extensions written in C or C++. For example the numpy package implements classes written in C.
One of the main reasons to do this is that C or C++ run much faster than python, especially in numerical analysis applications.

[sneek]

There are many examples of extensions written in C or C++. For example the numpy package implements classes written in C.
One of the main reasons to do this is that C or C++ run much faster than python, especially in numerical analysis applications.

Hi, thanks for your reply. I understand that C will compute some things much faster but I was wondering about the fact that the python documentation says that you CAN NOT implement new build-in objects in python so you have to use C/C++ for that.

[Gribouillis]

Hi, thanks for your reply. I understand that C will compute some things much faster but I was wondering about the fact that the python documentation says that you CAN NOT implement new build-in objects in python so you have to use C/C++ for that.

I think it's only the terminology of the python documentation. Usually the documentation opposes 'user defined types' implemented in python to 'built in types' implemented in C.

[sneek]

I think it's only the terminology of the python documentation. Usually the documentation opposes 'user defined types' implemented in python to 'built in types' implemented in C.

mmmm...ok. So you mean that if they call something a build-in type they just want to mention that it's something implemented in C but there are no types that you can only implement by using a C-Extension?

[Gribouillis]

mmmm...ok. So you mean that if they call something a build-in type they just want to mention that it's something implemented in C but there are no types that you can only implement by using a C-Extension?

The standard library has examples of modules wich offer 2 implementations, a C and a pure python implementation. For example Pickle and cPickle and StringIO and cStringIO. For most problems, you can imagine a python implementation, but on certain problems, this python implemenation will be very inefficient. For example, if you're writing an editor which manipulates a document as a big tree of lightweight objects, a C implementation will be more efficient, because it's easier to define lightweight objects in C than in python.

[sneek]

The standard library has examples of modules wich offer 2 implementations, a C and a pure python implementation. For example Pickle and cPickle and StringIO and cStringIO. For most problems, you can imagine a python implementation, but on certain problems, this python implemenation will be very inefficient. For example, if you're writing an editor which manipulates a document as a big tree of lightweight objects, a C implementation will be more efficient, because it's easier to define lightweight objects in C than in python.

oh ok I got that, but if there is a more efficient way by using e.g. cPickle or cStringIO why should I use the python implementation if the result is the same but the performance is worse?

[Gribouillis]

There are small differences, for example in Pickle, there are Pickler and Unpickler classes which don't exist in cPickle. Often such double implementations exist because someone first wrote a python module and then tried to speed it up by writing a C module. It's a good strategy, because the development time of the pure python version is usually small as compared to the C version.

[vegaseat]

Gribouillis hit it right. Another observation, the C version of a module, method or function is built-into the compiled interpreter itself (or in the form of a dll or pyd file). Python language versions are in the Lib directory.

I can only speak for the Windows version of Python here.

[pythopian]

why should I use the python implementation if the result is the same but the performance is worse?

For portability, for instance. Sometimes a C version is not available on all platforms, or not at the same time at least, so what you do is

try:
  import cFoo as Foo
except ImportError:
  import Foo
...
Foo.bar()