Commit 19fa9fbf authored by Dag Sverre Seljebotn's avatar Dag Sverre Seljebotn

Moving the CPython API to cpython. namespace

--HG--
rename : Cython/Includes/python.pxd => Cython/Includes/cpython/__init__.pxd
rename : Cython/Includes/python_bool.pxd => Cython/Includes/cpython/bool.pxd
rename : Cython/Includes/python_buffer.pxd => Cython/Includes/cpython/buffer.pxd
rename : Cython/Includes/python_bytes.pxd => Cython/Includes/cpython/bytes.pxd
rename : Cython/Includes/python_cobject.pxd => Cython/Includes/cpython/cobject.pxd
rename : Cython/Includes/python_complex.pxd => Cython/Includes/cpython/complex.pxd
rename : Cython/Includes/python_dict.pxd => Cython/Includes/cpython/dict.pxd
rename : Cython/Includes/python_exc.pxd => Cython/Includes/cpython/exc.pxd
rename : Cython/Includes/python_float.pxd => Cython/Includes/cpython/float.pxd
rename : Cython/Includes/python_function.pxd => Cython/Includes/cpython/function.pxd
rename : Cython/Includes/python_getargs.pxd => Cython/Includes/cpython/getargs.pxd
rename : Cython/Includes/python_instance.pxd => Cython/Includes/cpython/instance.pxd
rename : Cython/Includes/python_int.pxd => Cython/Includes/cpython/int.pxd
rename : Cython/Includes/python_iterator.pxd => Cython/Includes/cpython/iterator.pxd
rename : Cython/Includes/python_list.pxd => Cython/Includes/cpython/list.pxd
rename : Cython/Includes/python_long.pxd => Cython/Includes/cpython/long.pxd
rename : Cython/Includes/python_mapping.pxd => Cython/Includes/cpython/mapping.pxd
rename : Cython/Includes/python_mem.pxd => Cython/Includes/cpython/mem.pxd
rename : Cython/Includes/python_method.pxd => Cython/Includes/cpython/method.pxd
rename : Cython/Includes/python_module.pxd => Cython/Includes/cpython/module.pxd
rename : Cython/Includes/python_number.pxd => Cython/Includes/cpython/number.pxd
rename : Cython/Includes/python_object.pxd => Cython/Includes/cpython/object.pxd
rename : Cython/Includes/python_oldbuffer.pxd => Cython/Includes/cpython/oldbuffer.pxd
rename : Cython/Includes/python_pycapsule.pxd => Cython/Includes/cpython/pycapsule.pxd
rename : Cython/Includes/python_ref.pxd => Cython/Includes/cpython/ref.pxd
rename : Cython/Includes/python_sequence.pxd => Cython/Includes/cpython/sequence.pxd
rename : Cython/Includes/python_set.pxd => Cython/Includes/cpython/set.pxd
rename : Cython/Includes/python_string.pxd => Cython/Includes/cpython/string.pxd
rename : Cython/Includes/python_tuple.pxd => Cython/Includes/cpython/tuple.pxd
rename : Cython/Includes/python_type.pxd => Cython/Includes/cpython/type.pxd
rename : Cython/Includes/python_unicode.pxd => Cython/Includes/cpython/unicode.pxd
rename : Cython/Includes/python_version.pxd => Cython/Includes/cpython/version.pxd
rename : Cython/Includes/python_weakref.pxd => Cython/Includes/cpython/weakref.pxd
rename : tests/run/libc_stdlib.pyx => tests/run/cython_includes.pyx
parent 13f574a3
#####################################################################
#
# These are the Cython pxd files for (most of) the Python/C API.
#
# REFERENCE COUNTING:
#
# JUST TO SCARE YOU:
# If you are going to use any of the Python/C API in your Cython
# program, you might be responsible for doing reference counting.
# Read http://docs.python.org/api/refcounts.html which is so
# important I've copied it below.
#
# For all the declaration below, whenver the Py_ function returns
# a *new reference* to a PyObject*, the return type is "object".
# When the function returns a borrowed reference, the return
# type is PyObject*. When Cython sees "object" as a return type
# it doesn't increment the reference count. When it sees PyObject*
# in order to use the result you must explicitly cast to <object>,
# and when you do that Cython increments the reference count wether
# you want it to or not, forcing you to an explicit DECREF (or leak memory).
# To avoid this we make the above convention. Note, you can
# always locally override this convention by putting something like
#
# cdef extern from "Python.h":
# PyObject* PyNumber_Add(PyObject *o1, PyObject *o2)
#
# in your file after any .pxi includes. Cython will use the latest
# declaration.
#
# Cython takes care of this automatically for anything of type object.
## More precisely, I think the correct convention for
## using the Python/C API from Pyrex is as follows.
##
## (1) Declare all input arguments as type "object". This way no explicit
## <PyObject*> casting is needed, and moreover Pyrex doesn't generate
## any funny reference counting.
## (2) Declare output as object if a new reference is returned.
## (3) Declare output as PyObject* if a borrowed reference is returned.
##
## This way when you call objects, no cast is needed, and if the api
## calls returns a new reference (which is about 95% of them), then
## you can just assign to a variable of type object. With borrowed
## references if you do an explicit typecast to <object>, Pyrex generates an
## INCREF and DECREF so you have to be careful. However, you got a
## borrowed reference in this case, so there's got to be another reference
## to your object, so you're OK, as long as you relealize this
## and use the result of an explicit cast to <object> as a borrowed
## reference (and you can call Py_INCREF if you want to turn it
## into another reference for some reason).
#
# "The reference count is important because today's computers have
# a finite (and often severely limited) memory size; it counts how
# many different places there are that have a reference to an
# object. Such a place could be another object, or a global (or
# static) C variable, or a local variable in some C function. When
# an object's reference count becomes zero, the object is
# deallocated. If it contains references to other objects, their
# reference count is decremented. Those other objects may be
# deallocated in turn, if this decrement makes their reference
# count become zero, and so on. (There's an obvious problem with
# objects that reference each other here; for now, the solution is
# ``don't do that.'')
#
# Reference counts are always manipulated explicitly. The normal
# way is to use the macro Py_INCREF() to increment an object's
# reference count by one, and Py_DECREF() to decrement it by
# one. The Py_DECREF() macro is considerably more complex than the
# incref one, since it must check whether the reference count
# becomes zero and then cause the object's deallocator to be
# called. The deallocator is a function pointer contained in the
# object's type structure. The type-specific deallocator takes
# care of decrementing the reference counts for other objects
# contained in the object if this is a compound object type, such
# as a list, as well as performing any additional finalization
# that's needed. There's no chance that the reference count can
# overflow; at least as many bits are used to hold the reference
# count as there are distinct memory locations in virtual memory
# (assuming sizeof(long) >= sizeof(char*)). Thus, the reference
# count increment is a simple operation.
#
# It is not necessary to increment an object's reference count for
# every local variable that contains a pointer to an object. In
# theory, the object's reference count goes up by one when the
# variable is made to point to it and it goes down by one when the
# variable goes out of scope. However, these two cancel each other
# out, so at the end the reference count hasn't changed. The only
# real reason to use the reference count is to prevent the object
# from being deallocated as long as our variable is pointing to
# it. If we know that there is at least one other reference to the
# object that lives at least as long as our variable, there is no
# need to increment the reference count temporarily. An important
# situation where this arises is in objects that are passed as
# arguments to C functions in an extension module that are called
# from Python; the call mechanism guarantees to hold a reference
# to every argument for the duration of the call.
#
# However, a common pitfall is to extract an object from a list
# and hold on to it for a while without incrementing its reference
# count. Some other operation might conceivably remove the object
# from the list, decrementing its reference count and possible
# deallocating it. The real danger is that innocent-looking
# operations may invoke arbitrary Python code which could do this;
# there is a code path which allows control to flow back to the
# user from a Py_DECREF(), so almost any operation is potentially
# dangerous.
#
# A safe approach is to always use the generic operations
# (functions whose name begins with "PyObject_", "PyNumber_",
# "PySequence_" or "PyMapping_"). These operations always
# increment the reference count of the object they return. This
# leaves the caller with the responsibility to call Py_DECREF()
# when they are done with the result; this soon becomes second
# nature.
#
# Now you should read http://docs.python.org/api/refcountDetails.html
# just to be sure you understand what is going on.
#
#################################################################
from cpython.version cimport *
from cpython.ref cimport *
from cpython.exc cimport *
from cpython.module cimport *
from cpython.mem cimport *
from cpython.tuple cimport *
from cpython.list cimport *
from cpython.object cimport *
from cpython.sequence cimport *
from cpython.mapping cimport *
from cpython.iterator cimport *
from cpython.type cimport *
from cpython.number cimport *
from cpython.int cimport *
from cpython.bool cimport *
from cpython.long cimport *
from cpython.float cimport *
from cpython.complex cimport *
from cpython.string cimport *
from cpython.unicode cimport *
from cpython.dict cimport *
from cpython.instance cimport *
from cpython.function cimport *
from cpython.method cimport *
from cpython.weakref cimport *
from cpython.getargs cimport *
# Python <= 2.x
from cpython.cobject cimport *
from cpython.oldbuffer cimport *
# Python >= 2.4
from cpython.set cimport *
# Python >= 2.6
from cpython.buffer cimport *
from cpython.bytes cimport *
# Python >= 3.0
from cpython.pycapsule cimport *
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
ctypedef struct va_list
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
#####################################################################
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_unicode cimport Py_UNICODE
from cpython.unicode cimport Py_UNICODE
cdef extern from "Python.h":
ctypedef long long PY_LONG_LONG
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
ctypedef struct _inittab
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject, PyTypeObject
from cpython.ref cimport PyObject, PyTypeObject
from stdio cimport FILE
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
# available since Python 3.1!
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
ctypedef struct va_list
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
from python_ref cimport PyObject
from cpython.ref cimport PyObject
cdef extern from "Python.h":
......
#####################################################################
#
# These are the Cython pxd files for (most of) the Python/C API.
#
# REFERENCE COUNTING:
#
# JUST TO SCARE YOU:
# If you are going to use any of the Python/C API in your Cython
# program, you might be responsible for doing reference counting.
# Read http://docs.python.org/api/refcounts.html which is so
# important I've copied it below.
#
# For all the declaration below, whenver the Py_ function returns
# a *new reference* to a PyObject*, the return type is "object".
# When the function returns a borrowed reference, the return
# type is PyObject*. When Cython sees "object" as a return type
# it doesn't increment the reference count. When it sees PyObject*
# in order to use the result you must explicitly cast to <object>,
# and when you do that Cython increments the reference count wether
# you want it to or not, forcing you to an explicit DECREF (or leak memory).
# To avoid this we make the above convention. Note, you can
# always locally override this convention by putting something like
#
# cdef extern from "Python.h":
# PyObject* PyNumber_Add(PyObject *o1, PyObject *o2)
#
# in your file after any .pxi includes. Cython will use the latest
# declaration.
#
# Cython takes care of this automatically for anything of type object.
## More precisely, I think the correct convention for
## using the Python/C API from Pyrex is as follows.
##
## (1) Declare all input arguments as type "object". This way no explicit
## <PyObject*> casting is needed, and moreover Pyrex doesn't generate
## any funny reference counting.
## (2) Declare output as object if a new reference is returned.
## (3) Declare output as PyObject* if a borrowed reference is returned.
##
## This way when you call objects, no cast is needed, and if the api
## calls returns a new reference (which is about 95% of them), then
## you can just assign to a variable of type object. With borrowed
## references if you do an explicit typecast to <object>, Pyrex generates an
## INCREF and DECREF so you have to be careful. However, you got a
## borrowed reference in this case, so there's got to be another reference
## to your object, so you're OK, as long as you relealize this
## and use the result of an explicit cast to <object> as a borrowed
## reference (and you can call Py_INCREF if you want to turn it
## into another reference for some reason).
#
# "The reference count is important because today's computers have
# a finite (and often severely limited) memory size; it counts how
# many different places there are that have a reference to an
# object. Such a place could be another object, or a global (or
# static) C variable, or a local variable in some C function. When
# an object's reference count becomes zero, the object is
# deallocated. If it contains references to other objects, their
# reference count is decremented. Those other objects may be
# deallocated in turn, if this decrement makes their reference
# count become zero, and so on. (There's an obvious problem with
# objects that reference each other here; for now, the solution is
# ``don't do that.'')
#
# Reference counts are always manipulated explicitly. The normal
# way is to use the macro Py_INCREF() to increment an object's
# reference count by one, and Py_DECREF() to decrement it by
# one. The Py_DECREF() macro is considerably more complex than the
# incref one, since it must check whether the reference count
# becomes zero and then cause the object's deallocator to be
# called. The deallocator is a function pointer contained in the
# object's type structure. The type-specific deallocator takes
# care of decrementing the reference counts for other objects
# contained in the object if this is a compound object type, such
# as a list, as well as performing any additional finalization
# that's needed. There's no chance that the reference count can
# overflow; at least as many bits are used to hold the reference
# count as there are distinct memory locations in virtual memory
# (assuming sizeof(long) >= sizeof(char*)). Thus, the reference
# count increment is a simple operation.
#
# It is not necessary to increment an object's reference count for
# every local variable that contains a pointer to an object. In
# theory, the object's reference count goes up by one when the
# variable is made to point to it and it goes down by one when the
# variable goes out of scope. However, these two cancel each other
# out, so at the end the reference count hasn't changed. The only
# real reason to use the reference count is to prevent the object
# from being deallocated as long as our variable is pointing to
# it. If we know that there is at least one other reference to the
# object that lives at least as long as our variable, there is no
# need to increment the reference count temporarily. An important
# situation where this arises is in objects that are passed as
# arguments to C functions in an extension module that are called
# from Python; the call mechanism guarantees to hold a reference
# to every argument for the duration of the call.
#
# However, a common pitfall is to extract an object from a list
# and hold on to it for a while without incrementing its reference
# count. Some other operation might conceivably remove the object
# from the list, decrementing its reference count and possible
# deallocating it. The real danger is that innocent-looking
# operations may invoke arbitrary Python code which could do this;
# there is a code path which allows control to flow back to the
# user from a Py_DECREF(), so almost any operation is potentially
# dangerous.
#
# A safe approach is to always use the generic operations
# (functions whose name begins with "PyObject_", "PyNumber_",
# "PySequence_" or "PyMapping_"). These operations always
# increment the reference count of the object they return. This
# leaves the caller with the responsibility to call Py_DECREF()
# when they are done with the result; this soon becomes second
# nature.
#
# Now you should read http://docs.python.org/api/refcountDetails.html
# just to be sure you understand what is going on.
#
#################################################################
from python_version cimport *
from python_ref cimport *
from python_exc cimport *
from python_module cimport *
from python_mem cimport *
from python_tuple cimport *
from python_list cimport *
from python_object cimport *
from python_sequence cimport *
from python_mapping cimport *
from python_iterator cimport *
from python_type cimport *
from python_number cimport *
from python_int cimport *
from python_bool cimport *
from python_long cimport *
from python_float cimport *
from python_complex cimport *
from python_string cimport *
from python_unicode cimport *
from python_dict cimport *
from python_instance cimport *
from python_function cimport *
from python_method cimport *
from python_weakref cimport *
from python_getargs cimport *
# Python <= 2.x
from python_cobject cimport *
from python_oldbuffer cimport *
# Python >= 2.4
from python_set cimport *
# Python >= 2.6
from python_buffer cimport *
from python_bytes cimport *
# Python >= 3.0
from python_pycapsule cimport *
# Present for backwards compatability
from cpython cimport *
from libc.stdio cimport sprintf
from python cimport PyType_Check
from cpython.type cimport PyType_Check as PyType_Check2
def libc_imports():
"""
>>> libc_imports()
hello
"""
cdef char buf[10]
sprintf(buf, b'hello')
print (<object>buf).decode('ASCII')
def python_imports():
"""
>>> python_imports()
True
False
True
False
"""
print PyType_Check(list)
print PyType_Check([])
print PyType_Check2(list)
print PyType_Check2([])
"""
>>> f()
'hello'
"""
from libc.stdio cimport sprintf
def f():
cdef char buf[10]
sprintf(buf, b'hello')
return str((<object>buf).decode('ASCII'))
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment