4.1 Introduction

From the viewpoint of of C access to Python services, we have:

1. "Very high level layer": two or three functions that let you exec or eval arbitrary Python code given as a string in a module whose name is given, passing C values in and getting C values out using mkvalue/getargs style format strings. This does not require the user to declare any variables of type "PyObject *". This should be enough to write a simple application that gets Python code from the user, execs it, and returns the output or errors.
2. "Abstract objects layer": which is the subject of this chapter. It has many functions operating on objects, and lest you do many things from C that you can also write in Python, without going through the Python parser.
3. "Concrete objects layer": This is the public type-dependent interface provided by the standard built-in types, such as floats, strings, and lists. This interface exists and is currently documented by the collection of include files provides with the Python distributions.

   From the point of view of Python accessing services provided by C modules:

4. "Python module interface": this interface consist of the basic routines used to define modules and their members. Most of the current extensions-writing guide deals with this interface.
5. "Built-in object interface": this is the interface that a new built-in type must provide and the mechanisms and rules that a developer of a new built-in type must use and follow.

The Python C object interface provides four protocols: object, numeric, sequence, and mapping. Each protocol consists of a collection of related operations. If an operation that is not provided by a particular type is invoked, then a standard exception, NotImplementedError is raised with a operation name as an argument. In addition, for convenience this interface defines a set of constructors for building objects of built-in types. This is needed so new objects can be returned from C functions that otherwise treat objects generically.

• 4.1.1 Memory Management