[Python-porting] Port of psycopg2

[John Machin]

On 9/12/2008 00: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.
> 

[already sent by mistake to Mark only]

Hello Mark [and others!],

I'm just starting to look at the ramifications of trying to support xlrd 
  on 2.1 to 2.6 plus 3.x with just one set of source files. It already 
has a timemachine module where all version-dependent code is isolated. 
Version-dependency is handled at load time by tests on sys.version. All 
other modules do:
     from timemachine import *
So far this has worked well enough with some compromises e.g. 
timemachine.py must be loadable on all supported versions, so this means 
all versions end up using "adict.has_key(k)" because "k in adict" causes 
a SyntaxError on 2.1.

It looks like I'm going to need to abandon the "one timemachine fits 
all" idea, and use customised ones: timemachine_21, ..._22_26, ..._3x. 
That leaves me with one distutils-related problem: it insists on 
compiling all included files when you do "setup.py install"; I don't 
want it to compile timemachine_21.py with Python 3.0  -- it would barf 
on "False = 0" :-) -- and vice versa. But I also don't want to have 
tarballs/installers that depend on the Python version, if possible.

One major annoyance so far is what to do with 2.x str literals. I'm 
resigned to going through all the string literals and ensuring that the 
"text" ones are written as u"foo" and that the others are written as 
....what??? I thought of making it b"foo" and lashing up a quick'n'dirty 
"3to2" back-porter.

Another possibility is writing it as b("foo"), with the timemachine 
defining an appropriate b function:
     b = lambda x: x # 2.x
     b = lambda x: x.encode('ascii') # 3.x
but the runtime overhead could be painful, especially in 3.x.

I do hope there's a simple solution that I've missed. What are others doing?

Cheers,
John