[Python-porting] Port of psycopg2

Brett Cannon brett at python.org
Tue Dec 9 19:25:21 CET 2008


On Tue, Dec 9, 2008 at 04:23, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-12-08 14:46, Mark Hammond wrote:
>>>> Is there anyone else here for whom the step of "port to python 2.6"
>>> is a deal-breaker?
>>>
>>> I'm not sure where the problems would lie in porting to Python 2.6
>>> first.
>>
>> It's more about moving to Python 2.6 syntax *only*.  eg, using 'bytes' or
>> memory views etc as porting aids isn't that useful when targetting earlier
>> versions.  Further, I meant "deal breaker" in a figurative sense - ie, not a
>> real blocker, just an extra complication than what the "general" porting
>> guide might bother considering - but by implication, something that might be
>> worth addressing *somewhere*; eg, I'm finding '.encode('ascii')' a
>> reasonable porting aid for bytes objects in many 'demo' byte literal cases,
>> such as appending \0 chars, etc.
>>
>> 'Cheers'.encode('ascii'), ly,
>
> I think that one way or another you're going to end up using a
> Python porting module that collects all the helpers you need to
> support both Python 2 and 3.
>
> The same is going to be needed for C extensions.
>
> We're going to start moving all the Python version compatibility
> stuff into a new module for our code base. For the C extensions
> we already have a header file for the things we need in our
> tools. With Python 3, we're likely going to have to complement this
> with a separate C file for the various helper functions.
>

I suspect that, over time, best practices are going to emerge as
recipes that we should place in lib2to3 for people to use. Obviously
we should wait for those best practices to form, but definitely
something to be watching for.

-Brett


More information about the Python-porting mailing list