[Python-porting] Port of psycopg2

[M.-A. Lemburg]

On 2008-12-08 10:46, M.-A. Lemburg wrote:
> On 2008-12-06 23:12, Brett Cannon wrote:
>> On Sat, Dec 6, 2008 at 02:31, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> I created to run psycopg2 on Python 3.0, at
>>>
>>> http://www.dcl.hpi.uni-potsdam.de/home/loewis/psycopg_3k.diff
>>>
>>> I also submitted the patch to Frederico di Gregorio, who will
>>> integrate it when he finds time.
>>>
>>> The patch passes nearly all tests (the failures seem unrelated,
>>> since the unmodified code also fails in nearly the same way).
>>>
>> Martin, the porting machine!
>>
>> I know this keeps coming up, but I have not heard of a porting doc
>> being written yet. Is there one somewhere like the wiki?
> 
> FWIW: I posted a list of notes from our wiki some days ago:
> 
> http://mail.python.org/pipermail/python-porting/2008-November/000000.html
> 
> Good to see some action on this list :-)

We've since added these additional notes:

"""
== Notes for Python modules and package ==

 * Standard library was reorganized.

 See [http://www.python.org/dev/peps/pep-3108/ PEP 3108] for all the details.

 It's probably best to let 2to3 do the job of renaming imports.

 A couple of modules were also removed, e.g. the rfc822, popen2, urllib,
htmllib, UserList, UserDict, UserString modules. Their functionality is usually
available in one of the other more recent modules (e.g. the email package) or
via type subclassing.

 Others were removed without replacements, e.g. imputil, the string functions
wrapper (stringold), sgmllib.

 * new module is gone and so is types.ClassType

 To create new-style classes, you can use type() instead, e.g.
 {{{
myclass = type("MyClass", (object,), classdict)
}}}

 The above also works in Python 2.3 and onwards, so new code should start to be
written this way.

== Notes for C extensions ==

 * PyString_*() API have been renamed to PyBytes_*() and some were removed

 Check whether PyBytes_*() APIs and objects are really appropriate for the task
and switch to PyUnicode_*() APIs as necessary.

 * PyExc_StandardError no longer exists

 It should be replaced with PyExc_Exception.

 See [http://python.org/dev/peps/pep-0352/ PEP 352].

 * PyInt_*() APIs no longer exist.

 Python 3 uses the Python long implementation to store and handle integers.

 Use PyLong_*() APIs instead.

 PyInt_Check() uses should be either removed or changed to PyLong_Check().

 * Extension module initialization has changed completely in Python 3.

 See the
[http://docs.python.org/howto/cporting.html#module-initialization-and-state
porting howto] for an overview.

 Unfortunately, the Python 3 C API docs don't appear to have been updated to
this new method.

 * Type object initialization has changed.

 See [http://www.python.org/dev/peps/pep-3123/ PEP 3123] for details.

 You now have to write {{{
static PyTypeObject MyType = {
        PyVarObject_HEAD_INIT(NULL, 0)
        "MyType",
        ...
}
}}}
 instead of the version commonly found in Python 2 extensions: {{{
static PyTypeObject MyType = {
        PyObject_HEAD_INIT(&PyType_Type)
        0,                                      /* ob_size */
        "MyType",
        ...
}
}}}

 * The type slot interface has changed significantly.

 PyNumberMethods have changed due to removal of the division, oct, hex and
coercion slots.

 PySequenceMethods have changed, but maintained binary compatibility by
replacing the removed slice functions with dummy pointers.

 PyBufferProcs is a completely new design.

 A lot type flags were removed.

Questions:

 * The buffer object is gone in Python 3 and was replaced with a memoryview object.

 The memoryview object is just a wrapper around the low-level Py_buffer C struct
that represents buffers in Python 3.

 Strange enough, it is not clear how this can be used to efficiently access the
memory that the Py_buffer is maintaining. There are no macros defined for this
and the documentation points straight to the C struct members.

 [http://docs.python.org/dev/3.0/c-api/buffer.html Buffer documentation].

 The [http://www.python.org/dev/peps/pep-3118/ PEP 3118] describes the new API
in more detail and also gives a few examples.

 Overall, the whole buffer protocol design seems to have went overboard. We may
need to code our own little helper à la PyObject_AsReadBuffer() in Python 2.

"""

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 08 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-12-02: Released mxODBC.Connect 1.0.0      http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/