@@ -19,7 +19,7 @@ <h2>CXX</h2>
1919 exceptions into Python exceptions. As far as I can tell, CXX has no
2020 support for subclassing C++ extension types in Python. An even
2121 more significant difference is that a user's C++ code is still basically
22- “ dealing with Python objects” , though they are wrapped in
22+ `` dealing with Python objects'' , though they are wrapped in
2323 C++ classes. This means such jobs as argument parsing and conversion are
2424 still left to be done explicitly by the user.
2525
@@ -40,8 +40,8 @@ <h2>CXX</h2>
4040 < p >
4141 As far as I can tell, CXX enables one to write what is essentially
4242 idiomatic Python code in C++, manipulating Python objects through the
43- same fully-generic interfaces we use in Python. While you're hardly programming directly to the “ bare
44- metal” with CXX, it basically presents a “ C++-ized”
43+ same fully-generic interfaces we use in Python. While you're hardly programming directly to the `` bare
44+ metal'' with CXX, it basically presents a `` C++-ized''
4545 version of the Python 'C' API.
4646
4747 < p >
@@ -51,11 +51,11 @@ <h2>CXX</h2>
5151 fill in the other half. Here is his response to the commentary above:
5252
5353< blockquote >
54- “ My intention with CXX was not to do what you are doing. It was to enable a
54+ `` My intention with CXX was not to do what you are doing. It was to enable a
5555person to write an extension directly in C++ rather than C. I figured others had
5656the wrapping business covered. I thought maybe CXX would provide an easier
5757target language for those making wrappers, but I never explored
58- that.” < br > < i > -< a href ="mailto:dubois1@llnl.gov "> Paul Dubois</ a > </ i >
58+ that.'' < br > < i > -< a href ="mailto:dubois1@llnl.gov "> Paul Dubois</ a > </ i >
5959</ blockquote >
6060
6161 < h2 > SWIG</ h2 >
@@ -67,20 +67,20 @@ <h2>SWIG</h2>
6767 Perl or Tcl) extension module. It has been successfully used to create
6868 many Python extension modules. Like BPL, SWIG is trying to allow an
6969 existing interface to be wrapped with little or no change to the
70- existing code. The documentation says “ SWIG parses a form of ANSI C
70+ existing code. The documentation says `` SWIG parses a form of ANSI C
7171 syntax that has been extended with a number of special directives. As a
7272 result, interfaces are usually built by grabbing a header file and
73- tweaking it a little bit.” For C++ interfaces, the tweaking has often
73+ tweaking it a little bit.'' For C++ interfaces, the tweaking has often
7474 proven to amount to more than just a little bit. One user
7575 writes:
7676
77- < blockquote > “ The problem with swig (when I used it) is that it
77+ < blockquote > `` The problem with swig (when I used it) is that it
7878 couldnt handle templates, didnt do func overloading properly etc. For
7979 ANSI C libraries this was fine. But for usual C++ code this was a
8080 problem. Simple things work. But for anything very complicated (or
8181 realistic), one had to write code by hand. I believe BPL doesn't have
8282 this problem[< a href ="#sic "> sic</ a > ]... IMHO overloaded functions are very important to
83- wrap correctly.” < br > < i > -Prabhu Ramachandran</ i >
83+ wrap correctly.'' < br > < i > -Prabhu Ramachandran</ i >
8484 </ blockquote >
8585
8686 < p >
@@ -124,7 +124,7 @@ <h2>GRAD</h2>
124124 < a
125125 href ="http://www.python.org/workshops/1996-11/papers/GRAD/html/GRADcover.html "> GRAD</ a >
126126 is another very ambitious project aimed at generating Python wrappers for
127- interfaces written in “ legacy languages” , among which C++ is the first one
127+ interfaces written in `` legacy languages'' , among which C++ is the first one
128128 implemented. Like SWIG, it aims to parse source code and automatically
129129 generate wrappers, though it appears to take a more sophisticated approach
130130 to parsing in general and C++ in particular, so it should do a much better
@@ -152,9 +152,9 @@ <h2>Zope ExtensionClasses</h2>
152152 to support subclassing of extension types in Python, including
153153 multiple-inheritance. Both systems support pickling/unpickling of
154154 extension class instances in very similar ways. Both systems rely on the
155- same “ < a
155+ same `` < a
156156 href ="http://www.python.org/workshops/1994-11/BuiltInClasses/Welcome.html "> Don
157- Beaudry Hack</ a > ” that also inspired Don's MESS System.
157+ Beaudry Hack</ a > '' that also inspired Don's MESS System.
158158 < p >
159159 The major differences are:
160160 < ul >
@@ -177,23 +177,23 @@ <h2>Zope ExtensionClasses</h2>
177177 "http://www.digicool.com/releases/ExtensionClass/MultiMapping.html "> A
178178 Zope Example</ a > illustrates the differences.
179179 < li >
180- Zope's ExtensionClasses are specifically motivated by “ the need for a
181- C-based persistence mechanism” . BPL's are motivated by the desire
180+ Zope's ExtensionClasses are specifically motivated by `` the need for a
181+ C-based persistence mechanism'' . BPL's are motivated by the desire
182182 to simply reflect a C++ API into Python with as little modification as
183183 possible.
184184 < li >
185- The following Zope restriction does not apply to BPL: “ At most one
185+ The following Zope restriction does not apply to BPL: `` At most one
186186 base extension direct or indirect super class may define C data
187187 members. If an extension subclass inherits from multiple base
188188 extension classes, then all but one must be mix-in classes that
189- provide extension methods but no data.”
189+ provide extension methods but no data.''
190190 < li >
191191 Zope requires use of the somewhat funky inheritedAttribute (search for
192- “ inheritedAttribute” on < a
192+ `` inheritedAttribute'' on < a
193193 href ="http://www.digicool.com/releases/ExtensionClass "> this page</ a > )
194194 method to access base class methods. In BPL, base class methods can
195195 be accessed in the usual way by writing
196- “ < code > BaseClass.method</ code > ” .
196+ `` < code > BaseClass.method</ code > '' .
197197 < li >
198198 Zope supplies some creative but esoteric idioms such as < a href =
199199 "http://www.digicool.com/releases/ExtensionClass/Acquisition.html ">
@@ -211,7 +211,7 @@ <h2>Zope ExtensionClasses</h2>
211211 < p >
212212 © Copyright David Abrahams 2000. Permission to copy, use, modify,
213213 sell and distribute this document is granted provided this copyright
214- notice appears in all copies. This document is provided “ as is” without
214+ notice appears in all copies. This document is provided `` as is'' without
215215 express or implied warranty, and with no claim as to its suitability
216216 for any purpose.
217217 < p >
0 commit comments