coding for multiple versions of python

[Tim Arnold]

Hi,
I've got a python based system that has to run on hp unix and red hat linux.
The Python version on the HP is 2.4 and the version on the Linux box is 2.6.
There's nothing I can do about that.

I think that means I must have two different libraries since the pyc files
are not cross-version compatible. No problem for the libs like PIL or lxml.
But for the part of the system I actually code every day, I'd rather not do
dual maintenance, having two copies of my code for each platform/version.

I'm guessing I need to configure cvs to copy files to both locations
whenever I commit. Does that sound right? Is there a better way I'm not
thinking of?

thanks,
--Tim

 

[akonsu]

Hi,
I've got a python based system that has to run on hp unix and red hat linux.
The Python version on the HP is 2.4 and the version on the Linux box is 2..6.
There's nothing I can do about that.

I think that means I must have two different libraries since the pyc files
are not cross-version compatible. No problem for the libs like PIL or lxml.
But for the part of the system I actually code every day, I'd rather not do
dual maintenance, having two copies of my code for each platform/version.

I'm guessing I need to configure cvs to copy files to both locations
whenever I commit. Does that sound right? Is there a better way I'm not
thinking of?

thanks,
--Tim

hello,

why would you need to maintain pyc files at all? is having just source
files enough? or am i missing something?

konstantin

 

[Chris Rebert]

Hi,
I've got a python based system that has to run on hp unix and red hat linux.
The Python version on the HP is 2.4 and the version on the Linux box is 2.6.
There's nothing I can do about that.

I think that means I must have two different libraries since the pyc files
are not cross-version compatible.

Why would the .pyc-s matter? They're just an optimization, which fall
back to the .py files. It only matters if the .py sourcecode files are
compatible with both versions.

But for the part of the system I actually code every day, I'd rather not do
dual maintenance, having two copies of my code for each platform/version.

I'm guessing I need to configure cvs to copy files to both locations
whenever I commit. Does that sound right? Is there a better way I'm not
thinking of?

Put your code's directory in the PYTHONPATH / sys.path of both Python versions.
You will still have to write code that works in both versions though.
Essentially, don't use any new syntax that's not present in the older
version, and you'll have to work around any new/changed functions you
use.

Cheers,
Chris

 

[Martin v. Löwis]

I'm guessing I need to configure cvs to copy files to both locations

whenever I commit. Does that sound right? Is there a better way I'm not
thinking of?

If the set of files doesn't change too often, you can use symlinks.
That's how Debian currently installs Python packages for multiple
versions on a single system.

Specifically, put the source code into /net/source/python/foo/*.py.
Then, on each system, put symlinks to all .py files into
lib/site-packages/foo. Then Python will place the .pyc files next
to the symlinks, not next to the actual .py files.

HTH,
Martin

 

[Dave Angel]

Just use one set of source files.



Why would he need two sets of .py files?

I can't speak for Martin, but his description doesn't have two sets of
..py files, but two sets of symlinks pointing to the same .py files.
It's the .pyc files that exist in two forms, since those are version
dependent.

He's assuming:
1) an OS that supports symlinks
2) two versions of Python on same system
3) one set of pure-python sources that want to stay in synch for
both versions.

 

[Tim Arnold]

Hi,
I've got a python based system that has to run on hp unix and red hat
linux. The Python version on the HP is 2.4 and the version on the Linux
box is 2.6. There's nothing I can do about that.

I think that means I must have two different libraries since the pyc files
are not cross-version compatible. No problem for the libs like PIL or
lxml. But for the part of the system I actually code every day, I'd rather
not do dual maintenance, having two copies of my code for each
platform/version.

I'm guessing I need to configure cvs to copy files to both locations
whenever I commit. Does that sound right? Is there a better way I'm not
thinking of?

thanks,
--Tim

Thanks everyone. I assumed wrongly that I would run into problems if a pyc
file generated for 2.4 was available when 2.6 was running the code. I see
now that if the pyc is incompatible, python falls back to the py file. Makes
sense, I was trying to solve a problem I didn't actually have.

On the other hand, Martin's solution looks great for this situation. I'll
keep my single set of python files and link to them from the different
platform/python version dirs, so I can still get the optimization of the pyc
files.

I really love this group. thanks again,
--Tim Arnold

 

[Martin v. Löwis]

Specifically, put the source code into /net/source/python/foo/*.py.

Why would he need two sets of .py files?

As Dave explains:
So that the Python 2.4 installation on HP can write its own .pyc
files on disk next to the source files, and Python 2.6 can write
its .pyc files next to the sources on Linux.

Regards,
Martin

 

[Martin v. Löwis]

He's assuming:
1) an OS that supports symlinks
2) two versions of Python on same system
3) one set of pure-python sources that want to stay in synch for both
versions.

Actually, the OP said he has HP(-UX, I assume), and Linux, so it would
be two versions of Python on different systems - I also assume that he
has an NFS server that both can mount (or that one machine can NFS mount
the other).

Regards,
Martin