[Python-Dev] Providing support files to assist 3.x extension authors

Nick Coghlan ncoghlan at gmail.com
Sun Dec 20 03:37:18 CET 2009


Case Vanhorsen wrote:
> Hello,
> 
> When I ported gmpy (Python to GMP multiple precision library) to
> Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I
> found the code to slightly faster and cleaner than using PyLong_AsLong
> and checking for overflow. I looked at making PyLong_AsLongAndOverflow
> available to Python 2.x. http://bugs.python.org/issue7528 includes a
> patch that adds PyLong_AsLongAndOverflow to Python 2.7.
> 
> I also included a file (py3intcompat.c) that can be included with an
> extension's source code and provides PyLong_AsLongAndOverflow to
> earlier versions of Python 2.x. In the bug report, I suggested that
> py3intcompat.c could be included in the Misc directory and be made
> available to extension authors. This follows the precedent of
> pymemcompat.h. But there may be more "compatibility" files that could
> benefit extension authors. Mark Dickinson suggested that I bring the
> topic on python-dev.
> 
> Several questions come to mind:
> 
> 1) Is it reasonable to provide backward compatibility files (either as
> .h or .c) to provide support to new API calls to extension authors?

As a minor terminology nit, I'd call these "forward compatibility" files
- they're backports of Py3k interfaces to 2.x to make it easier to write
modules that will compile with both 2.x and 3.x.

> 2) If yes, should they be included with the Python source or
> distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki
> page)

That depends - if we're only targeting 2.7, then including the
compatibility files directly in the Python source would be fine. But for
a solution to be usable with extensions intended for use with 2.6 (or
even 2.5) it would be necessary to distribute the forward compatibility
files separately.

> 3) If not, and extension authors can create their own compatibility
> files, are there any specific attribution or copyright messages that
> must be included? (I assuming the compatibility was done by extracting
> the code for the new API and tweaking it to run on older versions of
> Python.)

For code extracted from the Python source, the PSF licenses would still
apply.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list