Extension Types + + + +

extension types

cdef class Shrubbery:
    cdef int width, height
    def __init__(self, w, h):
cdef class Shrubbery:
    cdef int width, height
    def __init__(self, w, h):
        self.width = w
        self.height = h
    def describe(self):
    def describe(self):
        print "This shrubbery is", 
 self.width, \
           
 "by", self.height, "cubits."
public
readonly
cdef class Shrubbery:
cdef class Shrubbery:
    cdef public int width, height
    cdef readonly float depth
width
height
depth
object
readonly
public
readonly
public
readonly
cdef widen_shrubbery(Shrubbery sh, extra_width):
cdef widen_shrubbery(sh, extra_width): # 
    sh.width = sh.width + extra_width
public
readonly
cdef widen_shrubbery(Shrubbery sh, extra_width):
    sh.width = sh.width + extra_width
widen_shrubbery
def widen_shrubbery(Shrubbery sh, extra_width): # This is
def widen_shrubbery(Shrubbery sh, extra_width): # This is
    sh.width = sh.width + extra_width          
 # dangerous!
sh
def widen_shrubbery(Shrubbery sh, extra_width):
def widen_shrubbery(Shrubbery sh, extra_width):
    if sh is None:
        raise TypeError
    sh.width = sh.width + extra_width
not None
def widen_shrubbery(Shrubbery sh not None, extra_width):
    sh.width = sh.width + extra_width
sh
not None
def
cdef
x
x is None
x is not None
x == None
x != None
x
if x: ...
cdef class Spam:
    property cheese:
        "A doc string can go
+
cdef class Spam:     
+  
+      property cheese: 
+
+
+     
+  
+          "A doc string can go
 here."   
-             def __get__(self):
+
+
+     
+  
+  
        def __get__(self):
   

+
+
               
 # This is called when the property is read. 

+
+
               
 ...   
-             def __set__(self, value):
+
+
+     
+  
+  
        def __set__(self, value):
   

+
+
               
 # This is called when the property is written. 

+
+
               
 ...   
-             def __del__(self):
+
+
+     
+  
+  
        def __del__(self):
   

+
+
               
 # This is called when the property is deleted. 

+
+
   
+
+
  

+
+
   The __get__, __set__ and __del__ methods are
 all optional; if they are omitted, an exception will be raised when the corresponding 
 operation is attempted.  
 Here's a complete example. It defines a property which adds to a list
 each time it is written to, returns the list when it is read, and empties
 the list when it is deleted. 

+
+
    
-  
+
+
+ 
+ 
+
+
+
   
+
+
      
+
+
   
+
+
    
+
+
   
+
+
    
+
+
   
+
+
    
+
+
   
+
+
    
+
+
   
+
+
   
+
+
    
+
+
   
+
+
   
-      cheesy.pyx Test input
cdef class CheeseShop:
-              cdef object cheeses 
-               def __new__(self): 

+            
+      
+      
  cdef object cheeses 
+
+
+             
+      
+        def __new__(self): 

+
+
            self.cheeses = [] 
-               property cheese: 
-                 def __get__(self): 

+
+
+             
+      
+      
  property cheese: 
+
+
+             
+      
+          def __get__(self): 

+
+
              return "We don't have: %s" % self.cheeses
       
-                 def __set__(self, value): 

+
+
+             
+      
+      
    def __set__(self, value): 

+
+
              self.cheeses.append(value)
       
-                 def __del__(self): 

+
+
+             
+      
+      
    def __del__(self): 

+
+
              del self.cheeses[:]
+
+
        from cheesy import CheeseShop
-            shop = CheeseShop() 

+            
+      
+      
shop = CheeseShop() 

+
+
        print shop.cheese 
-             shop.cheese = "camembert" 

+
+
+             
+      
+      
shop.cheese = "camembert" 

+
+
        print shop.cheese 
-             shop.cheese = "cheddar" 

+
+
+             
+      
+      
shop.cheese = "cheddar" 

+
+
        print shop.cheese 
-             del shop.cheese 

+
+
+             
+      
+      
del shop.cheese 

+
+
        print shop.cheese
+
+
        
Test output
We don't have: [] 

+
+
        We don't have: ['camembert'] 

+
+
        We don't have: ['camembert', 'cheddar'] 

+
+
        We don't have: []
 
+
+
+      
+  
+   
+
+
+
  
-    Subclassing
+
+
+   
+ Subclassing
+
+
   An extension type may inherit from a built-in type or another extension
 type:  
 cdef class Parrot: 

-       ...     cdef class Norwegian(Parrot): 

+
+
+       ...     
+  
+  
cdef class Norwegian(Parrot): 

+
+
        ...
+
+
  
-   

+
+
+   
+


+
+
  A complete definition of the base type must be available to Pyrex, so if 
 the base type is a built-in type, it must have been previously declared as 
 an extern extension type. If the base type is defined in another Pyrex 
 module, it must either be declared as an extern extension type or imported 
 using the cimport statement. 
- An extension type can only have one base class (no multiple inheritance).
+
+
+ 
+
An extension type can only have one base class (no multiple inheritance).
  
- Pyrex extension types can also be subclassed in Python. A Python class
+
+
+ 
+
Pyrex extension types can also be subclassed in Python. A Python class
  can inherit from multiple extension types provided that the usual Python
 rules for multiple inheritance are followed (i.e. the C layouts of all the
 base classes must be compatible).

+
+
  
- C methods
+
+
+ 
+C methods
+
+
  Extension types can have C methods as well as Python methods. Like C functions, 
 C methods are declared using cdef instead of def. C methods 
 are "virtual", and may be overridden in derived extension types.

+
+
  

- 
+
+
+ 
+
+
+
    
+
+
      
+
+
        
+
+
        
+
+
      
+
+
      
+
+
        
+
+
        
+
+
      
-     pets.pyx

+
+
        Output

+
+
        
cdef class Parrot:

+
+
        

+
+
     cdef void describe(self):

+
+
       print "This parrot is resting."

+
+
        

+
+
   cdef class Norwegian(Parrot):

+
+
        

+
+
     cdef void describe(self):

+
+
     Parrot.describe(self)

+
+
        print "Lovely plumage!"

+
+
        

+
+
        

+
+
  cdef Parrot p1, p2

+
+
     p1 = Parrot()

+
+
     p2 = Norwegian()

+
+
 print "p1:"

+
+
     p1.describe()

+
+
 print "p2:"

+
+
     p2.describe() 

+
+
        p1:

+
+
 This parrot is resting.

+
+
 p2:

+
+
       This parrot is resting.

+
+
    Lovely plumage!

+
+
        
 
+
+
+     
+  
+   
+
+
+
  

+
+
  The above example also illustrates that a C method can call an inherited
 C method using the usual Python technique, i.e.

+
+
 Parrot.describe(self)

+
+
 
- Forward-declaring extension types
+
+
+ 
+Forward-declaring extension types
+
+
   Extension types can be forward-declared, like struct and union types. This
  will be necessary if you have two extension types that need to refer to
 each other, e.g.  
-cdef class Shrubbery # forward declaration     cdef class Shrubber: 

+
cdef class Shrubbery # forward declaration     
+  
+  cdef class Shrubber: 

+
+
        cdef Shrubbery work_in_progress 
-     cdef class Shrubbery: 

+
+
+     
+  
+  
cdef class Shrubbery: 

+
+
        cdef Shrubber creator
+
+
  
+
+
    If you are forward-declaring an exension type that has a base class, you
 must specify the base class in both the forward declaration and its subsequent
 definition, for example,

+
+
 cdef class A(B)

+
+
   

+
+
 ...

+
+
   

+
+
 cdef class A(B):

+
+
     # attributes and methods

+
+
 
- Making extension types weak-referenceableBy
+
+
+ 
+Making extension types weak-referenceable
+
+By
 default, extension types do not support having weak references made to
 them. You can enable weak referencing by declaring a C attribute of
 type object called __weakref__. For example,

+
+
 

+
+
 cdef class ExplodingAnimal:

+
+
     """This animal will self-destruct when it is

+
+
        no longer strongly referenced."""

+
+
     

+
+
     cdef object __weakref__

+
+
 
+
+
 

+
+
 Public and external extension types
 
+
+
   Extension types can be declared extern or public. An extern extension type declaration makes 
 an extension type defined in external C code available to a Pyrex module. 
 A public extension type declaration makes an extension type defined in a Pyrex module available to external C 
 code.  
  External extension types
+
+
   An extern extension type allows you to gain access to the internals
  of Python objects defined in the Python core or in a non-Pyrex extension
 module.  
@@ -328,80 +854,191 @@
  module. While you can still do that, Pyrex 0.8 and later provides a better
  mechanism for this. See Sharing C Declarations Between
  Pyrex Modules.
+
+
   Here is an example which will let you get at the C-level members of the
 built-in complex object.  
-cdef extern from "complexobject.h":         struct Py_complex: 

+
cdef extern from "complexobject.h":     
+  
+      struct Py_complex: 

+
+
            double real 

+
+
            double imag 
-         ctypedef class __builtin__.complex [object PyComplexObject]:
+
+
+     
+  
+  
    ctypedef class __builtin__.complex [object PyComplexObject]:
   

+
+
            cdef Py_complex cval
   
-     # A function which uses the above type 

+
+
+     
+  
+  
# A function which uses the above type 

+
+
    def spam(complex c): 

+
+
        print "Real:", c.cval.real 

+
+
        print "Imag:", c.cval.imag
+
+
  
+
+
   Some important things to note are:  
 
+
+
    In this example, ctypedef class has been used. This is because,
  in the Python header files, the PyComplexObject struct is declared
  with

+
+
     

+
+
+    
+    
     ctypedef struct { 

+
+
         ... 

+
+
     } PyComplexObject;

+
+
     

+
+
     
-
As well as the name of the extension type, the module in which 
+
+
+  
+
+  As well as the name of the extension type, the module in which 
 its type object can be found is also specified. See the implicit importing section below.  

+
+
     

+
+
   
- When declaring an external extension type, you don't declare 
+
+
+  
 When declaring an external extension type, you don't declare 
 any methods. Declaration of methods is not required in order to call them, 
 because the calls are Python method calls. Also, as with structs and unions, 
 if your extension class declaration is inside a cdef extern from block,
  you only need to declare those C members which you wish to access.
-  
-    Implicit importing
-   Backwards Incompatibility Note:
+
+
+  
+
+
+
+   
+ Implicit importing
+
+
+   
+Backwards Incompatibility Note:
 You will have to update any pre-0.8 Pyrex modules you have which use extern
 extension types. I apologise for this, but for complicated reasons it proved
  to be too difficult to continue supporting the old way of doing these while
  introducing the new features that I wanted.
+
+
   Pyrex 0.8 and later requires you to include a module name in an extern
 extension class declaration, for example,  
 cdef extern class MyModule.Spam: 

+
+
        ...
+
+
   The type object will be implicitly imported from the specified module and
  bound to the corresponding name in this module. In other words, in this
 example an implicit  
 
-      from MyModule import Spam
-  
+
+
+      
+  
+  from MyModule import Spam
+
+
+  
+
+
+
   statement will be executed at module load time.  
 The module name can be a dotted name to refer to a module inside a package
  hierarchy, for example, 
- cdef extern class My.Nested.Package.Spam: 

+
+
+ 
+cdef extern class My.Nested.Package.Spam: 

+
+
        ...
+
+
   You can also specify an alternative name under which to import the type
 using an as clause, for example,  
 
+
+
    cdef extern class My.Nested.Package.Spam as Yummy: 

-      ... 
+
+
+      ... 
+
+
+
   which corresponds to the implicit import statement  
 
-      from My.Nested.Package import Spam as Yummy
-  
-    Type names vs. constructor names
+
+
+      
+  
+  from My.Nested.Package import Spam as Yummy
+
+
+  
+
+
+
+   
+ Type names vs. constructor names
+
+
   Inside a Pyrex module, the name of an extension type serves two distinct
  purposes. When used in an expression, it refers to a module-level global
 variable holding the type's constructor (i.e. its type-object). However,
 it can also be used as a C type name to declare variables, arguments and
 return values of that type.  
 When you declare 
- cdef extern class MyModule.Spam: 

+
+
+ 
+cdef extern class MyModule.Spam: 

+
+
        ...
+
+
   the name Spam serves both these roles. There may be other names
  by which you can refer to the constructor, but only Spam can be
 used as a type name. For example, if you were to explicity import MyModule,
@@ -409,21 +1046,34 @@
  wouldn't be able to use MyModule.Spam as a type name.  
 When an as clause is used, the name specified in the as
 clause also takes over both roles. So if you declare 
- cdef extern class MyModule.Spam as Yummy: 

+
+
+ 
+cdef extern class MyModule.Spam as Yummy: 

+
+
        ...
+
+
   then Yummy becomes both the type name and a name for the constructor.
  Again, there are other ways that you could get hold of the constructor,
 but only Yummy is usable as a type name.  
  Public extension types
+
+
   An extension type can be declared public, in which case a .h
 file is generated containing declarations for its object struct and type
 object. By including the .h file in external C code that you write,
 that code can access the attributes of the extension type.  
  Name specification clause
+
+
   The part of the class declaration in square brackets is a special feature
  only available for extern or public extension types. The full 
 form of this clause is  
 [object object_struct_name, type type_object_name ]
+
+
   where object_struct_name is the name to assume for the type's C
 struct, and type_object_name is the name to assume for the type's
 statically declared type object. (The object and type clauses can be written
@@ -433,12 +1083,30 @@
 generate code that is compatible with the declarations in the header file.
 Otherwise, for extern extension types, the object clause is
 optional. 
- For public extension types, the object and type clauses 
+
+
+ 
+
For public extension types, the object and type clauses 
 are both required, because Pyrex must be able to generate code that is compatible 
 with external C code. 
-  
- 
 

+
+
+ 
+ 
+
+
+ 
+
 

+
+
  Back to the Language Overview 

+
+
    

+
+
  

-
\ No newline at end of file
+
+
+
+

Modified: lxml/pyrex/Doc/overview.html
==============================================================================

--- lxml/pyrex/Doc/overview.html	(original)
+++ lxml/pyrex/Doc/overview.html	Wed Feb 14 15:20:32 2007
@@ -1,108 +1,216 @@
 
 
+
              
+  
   
 
+
              
-  
-  Pyrex Language Overview
-
+  
+  Pyrex Language Overview
+
 
+
      
-   
Overview of the Pyrex Language   
+   
+Overview of the Pyrex Language   
+
+
 
    This document informally describes the extensions to the Python language 
  made by Pyrex. Some day there will be a reference manual covering everything 
- in more detail. 

+ in more detail.  Contents
 
-     
- Contents
 
      
 
 
-    Basics
-           
+
+   Source Files and Compilation (Section added in 0.9.5)

+ 
Basics
+
+
+           
+  
+
     Python functions vs. C functions
+
      Python objects as parameters
-     C variable and type definitions
Automatic type conversions
+
+     C variable and type definitions
+    Automatic type conversions
+
+    
     
+
       Caveats when using a Python string in a C context
+
+    
     
 
+
      Scope rules
+
      Statements and expressions
-                 
+
+                 
+    
+
     Differences between C and Pyrex
 expressions

-
+
+        
+
      Integer for-loops
-                
+
+                
+    
+
      Error return values
-                 
+
+                 
+    
+
     Checking return values of non-Pyrex
  functions
-                
+
+                
+    
+
      The include statement
-          
+
+          
+  
+
      Interfacing with External C Code
-           
+
+           
+  
+
     External declarations
-                 
+
+                 
+    
+
     Referencing C header files
+
      Styles of struct/union/enum declaration
+
      Accessing Python/C API routines
+
      Resolving naming conflicts - C name specifications
-                
+
+                
+    
+
      Public declarations
-          
-     Extension Types (Section revised in 0.9)
-     Sharing Declarations Between Pyrex Modules
-     (NEW in 0.8)
+
+          
+  
+
+     Extension Types
+
+     Sharing Declarations Between Pyrex Modules
+
      Limitations
-           
+
+           
+  
+
     Unsupported Python features
+
      Semantic differences between Python
  and Pyrex
-          
+
+          
+  
+
     
 
 
+
      
-   
Basics   
+
   
 
+Source Files and Compilation

+
+


+Pyrex source file names consist of the name of the module followed by a .pyx extension, for example a module called primes would have a source file named primes.pyx.

+
+

 
-   This section describes the basic features of the Pyrex language. The facilities 
+If your module is destined to live in a package, the source file name should include the full dotted name that the module will eventually have. For example, a module called primes that will be installed in a package called numbers should have a source file called numbers.primes.pyx.
+This will ensure that the __name__ properties of the module and any
+classes defined in it are set correctly. If you don't do this, you may
+find that pickling doesn't work, among other problems. It also ensures
+that the Pyrex compiler has the right idea about the layout of the
+module namespace, which can be important when accessing extension types
+defined in other modules.

+

+Once you have written your .pyx file, there are a couple of ways of
+turning it into an extension module. One way is to compile it manually
+with the Pyrex compiler, e.g.

+

+pyrexc primes.pyx

+
+

+This will produce a file called primes.c,
+which then needs to be compiled with the C compiler using whatever
+options are appropriate on your platform for generating an extension
+module. There's a Makefile in the Demos directory (called Makefile.nodistutils) that shows how to do this for Linux.

+

+The other, and probably better, way is to use the distutils extension provided with Pyrex. See the Setup.py
+file in the Demos directory for an example of how to use it. This
+method has the advantage of being cross-platform -- the same setup file
+should work on any platform where distutils can compile an extension
+module.

+

+
+Language Basics   
+
+This section describes the basic features of the Pyrex language. The facilities 
  covered in this section allow you to create Python-callable functions that 
  manipulate C data structures and convert between Python and C data types. 
- Later sections will cover facilities for wrapping external C code, creating new Python types and cooperation between Pyrex modules.   
+ Later sections will cover facilities for wrapping external C code, creating new Python types and cooperation between Pyrex modules.

+   
  Python functions vs. C functions
 
+
    There are two kinds of function definition in Pyrex:   
 Python functions are defined using the def statement, as
  in Python. They take Python objects as parameters and return Python objects. 
  
 
+
    
 C functions are defined using the new cdef statement. They
  take either Python objects or C values as parameters, and can return either
  Python objects or C values. 
 
+
    
 Within a Pyrex module, Python functions and C functions can call each other
 freely, but only Python functions can be called from outside the module by
 interpreted Python code. So, any functions that you want to "export" from
  your Pyrex module must be declared as Python functions using def. 
 
+
    
 Parameters of either type of function can be declared to have C data types,
  using normal C declaration syntax. For example, 
 
+
    
-        def spam(int i, char *s):
    ...
-           cdef int eggs(unsigned long l, float f):
    ...
+        
+  def spam(int i, char *s):
    ...
+
+           
+  cdef int eggs(unsigned long l, float f):
    ...
+
    
 
+
    When a parameter of a Python function is declared to have a C data type, 
  it is passed in as a Python object and automatically converted to a C value, 
  if possible. Automatic conversion is currently only possible for numeric 
@@ -111,17 +219,22 @@
 C functions, on the other hand, can have parameters of any type, since 
  they're passed in directly using a normal C function call. 
 
+
    
  Python objects as parameters and return values
 
+
    If no type is specified for a parameter or return value, it is assumed 
  to be a Python object. (Note that this is different from the C convention, 
  where it would default to int.) For example, the following defines 
  a C function that takes two Python objects as parameters and returns a Python
  object:   
-        cdef spamobjs(x, y):
    ...
+        
+  cdef spamobjs(x, y):
    ...
+
    
 
+
    Reference counting for these objects is performed automatically according 
  to the standard Python/C API rules (i.e. borrowed references are taken as
  parameters and a new reference is returned).   
@@ -129,126 +242,217 @@
  as a Python object. This can be useful if the name being declared would otherwise
 be taken as the name of a type, for example, 
 
+
    
-        cdef ftang(object int):
    ...
+        
+  cdef ftang(object int):
    ...
+
    
 
+
    declares a parameter called int which is a Python object. You 
 can also use object as the explicit return type of a function, e.g. 
   
-        cdef object ftang(object int):
    ...
+        
+  cdef object ftang(object int):
    ...
+
    
 
+
    In the interests of clarity, it is probably a good idea to always be explicit 
  about object parameters in C functions.   
  C variable and type definitions
 
+
    The cdef statement is also used to declare C variables, either
 local  or module-level:   
-        cdef int i, j, k
cdef float f, g[42], *h
+        
+  cdef int i, j, k
cdef float f, g[42], *h
+
    
 
+
    and C struct, union or enum types:   
-        cdef struct Grail:
    int age
    float volume
-           cdef union Food:
    char *spam
    float *eggs
-           cdef enum CheeseType:
    cheddar, edam, 
    camembert
-           cdef enum CheeseState:
    hard = 1
    soft = 2
    runny = 3
+        
+  cdef struct Grail:
    int age
    float volume
+
+           
+  cdef union Food:
    char *spam
    float *eggs
+
+           
+  cdef enum CheeseType:
    cheddar, edam, 
    camembert
+
+           
+  cdef enum CheeseState:
    hard = 1
    soft = 2
    runny = 3
+
    
 
+
    There is currently no special syntax for defining a constant, but you
 can  use an anonymous enum declaration for this purpose, for example,   
 cdef enum: 

+
         tons_of_spam = 3
 
+
    Note that the words struct, union and enum are used only when defining a type, not when referring to it. For example, to declare a variable pointing 
  to a Grail you would write   
-        cdef Grail *gp
+        
+  cdef Grail *gp
+
    
 
+
    and not  
-        cdef struct Grail *gp # WRONG
+        
+  cdef struct Grail *gp # WRONG
+
    
 
+
    There is also a ctypedef statement for giving names to types, e.g. 
   
-        ctypedef unsigned long ULong
-           ctypedef int *IntPtr

+        
+  ctypedef unsigned long ULong
+
+           
+  ctypedef int *IntPtr

+
+
 
 Automatic type conversions
 
+
 In most situations, automatic conversions will be performed for the
 basic numeric and string types when a Python object is used in a
 context requiring a C value, or vice versa. The following table
 summarises the conversion possibilities.

 
+
 

 
+
 
 
+
   
+
     
+
       
+
       
+
       
+
     
+
     
+
       
+
       
+
       
+
     
+
     
+
     
 
+
     
+
       
+
       
+
       
+
     
+
     
+
       
       
       
     
+
     
+
       
+
       
+
       
+
     
+
     
+
       
+
       
+
       
+
     
+
+  
   C types

+
       From Python types

+
       To Python types

+
       
[unsigned] char

+
 [unsigned] short

+
       int, long int, long

+
       int

+
       
unsigned int

+
 unsigned long

+
       [unsigned] long long

 
+
       int, long

+
       

 
+
       long

+
       

 
+
       
float, double, long double

+
       int, long, float

+
       float

+
       
char *

+
       str

+
       str

+
       
 
 
+
 

 
+
 Caveats when using a Python string in a C context
 
+
 You need to be careful when using a Python string in a context expecting a char *.
 In this situation, a pointer to the contents of the Python string is
 used, which is only valid as long as the Python string exists. So you
@@ -257,12 +461,16 @@
 the Python string will live long enough, you will need to copy the C
 string.

 
+
 

 
+
 Pyrex detects and prevents some mistakes of this kind. For instance, if you attempt something like

 
+
 cdef char *s
s = pystring1 + pystring2
 
+
 then Pyrex will produce the error message "Obtaining char * from temporary Python value".
 The reason is that concatenating the two Python strings produces a new
 Python string object that is referenced only by a temporary internal
@@ -270,28 +478,37 @@
 the temporary variable will be decrefed and the Python string
 deallocated, leaving s dangling. Since this code could not possibly work, Pyrex refuses to compile it.

 
+
 

 
+
 The solution is to assign the result of the concatenation to a Python variable, and then obtain the char * from that, i.e.

 
+
 cdef char *s
p = pystring1 + pystring2
s = p

 
+
 It is then your responsibility to hold the reference p for as long as necessary.

 
+
 

 
+
 Keep in mind that the rules used to detect such errors are only
 heuristics. Sometimes Pyrex will complain unnecessarily, and sometimes
 it will fail to detect a problem that exists. Ultimately, you need to
 understand the issue and be careful what you do

`cheesy.pyx`	Test input
`cdef class CheeseShop:` - `cdef object cheeses` - `def __new__(self):` + + + `cdef object cheeses` + + + + + `def __new__(self):` + + `self.cheeses = []` - `property cheese:` - `def __get__(self):` + + + + + `property cheese:` + + + + + `def __get__(self):` + + `return "We don't have: %s" % self.cheeses` - `def __set__(self, value):` + + + + + `def __set__(self, value):` + + `self.cheeses.append(value)` - `def __del__(self):` + + + + + `def __del__(self):` + + `del self.cheeses[:]` + +	`from cheesy import CheeseShop` - `shop = CheeseShop()` + + + `shop = CheeseShop()` + + `print shop.cheese` - `shop.cheese = "camembert"` + + + + + `shop.cheese = "camembert"` + + `print shop.cheese` - `shop.cheese = "cheddar"` + + + + + `shop.cheese = "cheddar"` + + `print shop.cheese` - `del shop.cheese` + + + + + `del shop.cheese` + + `print shop.cheese` + +
	Test output
	`We don't have: []` + + `We don't have: ['camembert']` + + `We don't have: ['camembert', 'cheddar']` + + `We don't have: []`

`pets.pyx` + +	Output + +
`cdef class Parrot: + + + + cdef void describe(self): + + print "This parrot is resting." + + + + cdef class Norwegian(Parrot): + + + + cdef void describe(self): + + Parrot.describe(self) + + print "Lovely plumage!" + + + + + + cdef Parrot p1, p2 + + p1 = Parrot() + + p2 = Norwegian() + + print "p1:" + + p1.describe() + + print "p2:" + + p2.describe()` + +	`p1: + + This parrot is resting. + + p2: + +This parrot is resting. + +` `Lovely plumage!` + +

C types +	From Python types +	To Python types +
[unsigned] char + [unsigned] short + int, long	int, long +	int +
unsigned int + unsigned long + [unsigned] long long +	int, long + +	long + +
float, double, long double +	int, long, float +	float +
char * +	str +	str +

Extension Types + + + +

+Extension Types

Contents

Contents

Introduction

Introduction

Attributes

Attributes

Type declarations

Extension types and None

Special methods

Special methods

Properties

Subclassing

Subclassing

C methods

C methods

Forward-declaring extension types

Forward-declaring extension types

Making extension types weak-referenceable

Making extension types weak-referenceable

Public and external extension types

External extension types

Implicit importing

Implicit importing

Type names vs. constructor names

Type names vs. constructor names

Public extension types

Name specification clause

Overview of the Pyrex Language

+Overview of the Pyrex Language +

Contents

Contents

Basics +

Source Files and Compilation +

Language Basics +

Python functions vs. C functions

Python objects as parameters and return values

C variable and type definitions

Automatic type conversions

Caveats when using a Python string in a C context

+
Extension Types

+
Overview of the Pyrex Language +

Source Files and Compilation
+