Exception Handling (C - extending python)

[Lee]

Hi all,

Where does PyExc_TypeError (and alike) points to? I can see its
declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerrors.h
but I cannot figure out what it is its value, where it is
initialized.

Any help is greatly appreciated.

Lee

 

[Stefan Behnel]

Lee, 23.10.2011 06:09:

Where does PyExc_TypeError (and alike) points to? I can see its
declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerrors.h
but I cannot figure out what it is its value, where it is
initialized.

It gets initialised inside of the interpreter core and then points to a
Python object.

Any help is greatly appreciated.

The question is: why do you ask? What exactly do you want to do?

If you ask a more targeted question, you will get an answer that will help
you further.

Stefan

 

[Lee]

Thanks Stefan,

I am just interested to understand the mechanism inside python.

If it points to an object that means I can defered it (through
ob_type).
From there, how a function like PyErr_SetString knows what exception
is?
Where its value is kept?

Lee

 

[Stefan Behnel]

Hi,

note that I reformatted your posting to get the replies back into order.

Lee, 23.10.2011 13:32:

If it points to an object that means I can defered it (through
ob_type).

That will give you the "type" object, because PyExc_TypeError points to the
type "TypeError". Note that types are also objects in Python.

From there, how a function like PyErr_SetString knows what exception
is?

The type object that you pass in must inherit from the BaseException type.
You can read the code in Python/errors.c, function PyErr_SetObject().

I am just interested to understand the mechanism inside python.

That's just fine. If you are interested in the inner mechanics of the
CPython runtime, reading the source is a very good way to start getting
involved with the project.

However, many extension module authors don't care about these inner
mechanics and just use Cython instead. That keeps them from having to learn
the C-API of CPython, and from tying their code too deeply into the CPython
runtime itself.

Stefan

 

[Lee]

For a moment, back to the basics...

I am using the example provided by docs at 2.1.2
"Providing finer control...". Using say:

mynoddy = noddy2.Noddy()
mynoddy.first = "a"
mynoddy.last = 0

the last line causes an ugly crash (on python 2.6.5 on winxp).
No way to catch the exception.

As I understand from the docs, all PyErr_SetString does is to set an
exception,
what one has to do to raise this exception (in C)?

If I replace "return -1" in the Noddy_setlast() function with "return
NULL"
(well, the compiler will complain...) the program passes by without
raising an exception.

Any explanations?...

Lee

 

[Ulrich Eckhardt]

Am 23.10.2011 14:41, schrieb Stefan Behnel:

That's just fine. If you are interested in the inner mechanics of the
CPython runtime, reading the source is a very good way to start getting
involved with the project.

However, many extension module authors don't care about these inner
mechanics and just use Cython instead. That keeps them from having to
learn the C-API of CPython, and from tying their code too deeply into
the CPython runtime itself.

Could you elaborate a bit? What are the pros and cons of writing an
extension module using the Cython API compared to using the CPyothon
API? In particular, how portable is it? Can I compile a module in one
and use it in the other? Don't I just tie myself to a different API, but
tie myself nonetheless?

Thank you!

Uli

 

[Stefan Behnel]

Ulrich Eckhardt, 25.10.2011 08:49:

Am 23.10.2011 14:41, schrieb Stefan Behnel:

Could you elaborate a bit? What are the pros and cons of writing an
extension module using the Cython API compared to using the CPyothon API?

No cons.

Cython is not an API, it's a programming language. It's Python, but with
extended support for talking to C/C++ code (and also Fortran). That means
that you don't have to use the C-API yourself, because Cython will do it
for you.

In particular, how portable is it? Can I compile a module in one and use it
in the other?

They both use the CPython C-API internally. It's just that you are not
using it explicitly in your code, so you (can) keep your own code free of
CPython-isms.

It's substantially more portable than the "usual" hand-written code,
because it generates C code for you that compiles and works in CPython 2.4
up to the latest 3.3 in-development version, and also with all major C/C++
compilers, etc. It also generates faster glue code than you would write,
e.g. for data type conversion and argument unpacking in function calls. So
it speeds up thin wrappers automatically for you.

That doesn't mean that you can't get the same level of speed and
portability in hand-written code. It just means that you don't have to do
it yourself. Saves a lot of time, both during development and later during
the maintenance cycle. Basically, it allows you to focus on the
functionality you want to implement, rather than the implementation details
of CPython, and also keeps the maintenance overhead at that level for you.

Don't I just tie myself to a different API, but tie myself
nonetheless?

There's a port to plain Python+ctypes underways, for example, which you
could eventually use in PyPy. Try to do that at the C-API level.

Stefan