1. Dan Villiom Podlaski Christiansen
  2. Pyrex

Commits

gcewing  committed 66a1c47

De-documented cross-module forward declarations

  • Participants
  • Parent commits c0ebb66
  • Branches default

Comments (0)

Files changed (7)

File CHANGES.txt

View file
+0.9.8.5
+-------
+
+Deprecations:
+
+	- The features introducted in 0.9.8 and 0.9.8.1 for cross-forward-declaring
+		extension types between .pxd files turn out to be unnecessary, since
+		the circular import problems they are aimed at can be avoided using
+		ordinary forward delcarations in the .pxd files ahead of any cimports.
+
+
+0.9.8.4
+-------
+
+Bug fixes:
+
+	- Incorrect code generated for Python indexing with an unsigned int.
+		[Christopher Williams]
+
+
 0.9.8.3
 -------
 

File CHECKLIST.txt

View file
 Release Checklist
 =================
 
+# Update CHANGES.txt
+
 * Ensure all tests pass
 
 * cd Demos; make test
 
 * Tag release
 
-* make tar
+* cd ..; make tar
 
 * make upload

File Doc/Manual/sharing.html

View file
 must match the base class in the definition part.<h2><a class="mozTocH2" name="mozTocId144977"></a><a name="CircularCImports"></a>Circular cimports</h2>If
 you have two structs, unions or extension types defined in different
 .pxd files, and they need to refer to each other, there is a potential
-for problems with circular imports. To avoid this, there is a special
-form of cimport statement that also functions as a forward declaration.
-Its use is illustrated in the example below.<br><br><table style="text-align: left; margin-left: 40px;" border="1" cellpadding="5" cellspacing="2"><tbody><tr><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">foo.pxd</td><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">blarg.pxd</td></tr><tr><td style="vertical-align: top; white-space: nowrap; text-align: left; font-family: monospace; background-color: rgb(255, 204, 24);">from blarg cimport struct Eggs<br><br>cdef struct Spam:<br>&nbsp;&nbsp;&nbsp;&nbsp;Eggs *eggs</td><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">from foo cimport struct Spam<br><br>cdef struct Eggs:<br>&nbsp;&nbsp;&nbsp;&nbsp;Spam *spam</td></tr></tbody></table><br>We can't simply say<span style="font-family: monospace;"> from blarg cimport Eggs </span>and<span style="font-family: monospace;"> from foo cimport Spam</span>,
-because that would lead to circular import problems analogous to those
-that arise in Python when two modules try to import names from each
-other. Including the word <span style="font-family: monospace;">struct</span>
-in the cimport statement lets Pyrex know that the type being imported
-is going to be a struct type, so it can proceed before the full
-declaration is available.<br><br>As well as <span style="font-family: monospace;">struct</span>, you can also use <span style="font-family: monospace;">union</span> or <span style="font-family: monospace;">class</span>. If there are multiple struct, union or class names being imported, a separate keyword is required in front of each one, e.g.<br><br><div style="margin-left: 40px;"><span style="font-family: monospace;">from somewhere cimport class This, class That, union Other</span><br></div><br>Note
+for problems with circular imports. These problems can be avoided by
+placing forward declarations of all the structs, unions and extension
+types defined in the .pxd file <span style="font-style: italic;">before</span> the first <span style="font-family: monospace;">cimport</span> statement.<br><br>For example:<br><br><table style="text-align: left; margin-left: 40px;" border="1" cellpadding="5" cellspacing="2"><tbody><tr><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">foo.pxd</td><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">blarg.pxd</td></tr><tr><td style="vertical-align: top; white-space: nowrap; text-align: left; font-family: monospace; background-color: rgb(255, 204, 24);">cdef struct Spam<br><br>from blarg cimport Eggs<br><br>cdef struct Spam:<br>&nbsp;&nbsp;&nbsp;&nbsp;Eggs *eggs</td><td style="vertical-align: top; white-space: nowrap; text-align: left; background-color: rgb(255, 204, 24); font-family: monospace;">cdef struct Eggs<br><br>from foo cimport Spam<br><br>cdef struct Eggs:<br>&nbsp;&nbsp;&nbsp;&nbsp;Spam *spam</td></tr></tbody></table><br>If
+the forward declarations weren't present, a circular import problem
+would occur, analogous to that which arises in Python when two modules
+try to import names from each
+other. Placing the forward declarations before the <span style="font-family: monospace;">cimport</span> statements ensures that all type names are known to the Pyrex compiler sufficiently far in advance.<br><br>Note
 that any .pyx file is free to cimport anything it wants from any .pxd
-file without needing these declarations. It's only when two .pxd files
+file without needing this precaution. It's only when two .pxd files
 import each other that circular
 import issues arise. <hr width="100%">Back to the <a href="overview.html">Language Overview</a>
 <br>

File Pyrex/Compiler/Version.py

View file
-version = '0.9.8.3'
+version = '0.9.8.4'

File Tests/(Manual)/Circular/blarg.pxd

View file
-from foo cimport class Foo
+cdef class Blarg
+
+from foo cimport Foo
 
 cdef class Blarg:
 	cdef object name

File Tests/(Manual)/Circular/foo.pxd

View file
-from blarg cimport class Blarg
+cdef class Foo
+
+from blarg cimport Blarg
 
 cdef class Foo:
 	cdef object name

File Tests/10/package/inpackage.c

View file
-/* Generated by Pyrex */
+/* Generated by Pyrex 0.9.8.4 on Thu Jun 19 16:54:54 2008 */
 
 #define PY_SSIZE_T_CLEAN
 #include "Python.h"