Backwards compatability: opinions?
Hi folks -- I wonder if anyone has strong opinions as to which version(s) of Python the Distutils should support/require. I've found a number of silly little bugs in the 1.5.1 library (I'm coding on my home PC, which isn't running the latest beta... yet) that have been fixed in 1.5.2. The temptation is to assume that everyone is running 1.5.2, and if they're not... too bad. The alternative is to allow (at least) 1.5.1, and provide reimplementations of the buggy functions so that Distutils can work on pre-1.5.2 Pythons. I'm not super keen about either option; anyone have strong opinions one way or the other, or a "middle road" solution? Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg, My inclination is that 1.5.1 should be supported. Heck, it's still the current stable release! Even though 1.5.2 will probably be stable before distutils, 1.5.1 just isn't old enough to ignore. I think any compatibility hacks that are needed can go in a module "distutils.compat" (or some such) that gets imported by the "main" distutils module. The compat module can deal with any version checking and update installation it needs to; this makes the updates as transparent as possible to the rest of the code, and allows really old things to be taken out later. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives
On Wed, Mar 10, 1999 at 11:28:01AM -0500, Greg Ward wrote:
Hi folks --
I wonder if anyone has strong opinions as to which version(s) of Python the Distutils should support/require. I've found a number of silly little bugs in the 1.5.1 library (I'm coding on my home PC, which isn't running the latest beta... yet) that have been fixed in 1.5.2. The temptation is to assume that everyone is running 1.5.2, and if they're not... too bad.
The alternative is to allow (at least) 1.5.1, and provide reimplementations of the buggy functions so that Distutils can work on pre-1.5.2 Pythons.
Well, how about grabbing the fixed versions out of 1.5.2, shoving them into a sub-package (Distutils.Fixed), and then just loading the correct ones on startup? I don't think there's anything in the 1.5.2 library that can't be used under 1.5.1. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
Christopher Petrilli writes:
Well, how about grabbing the fixed versions out of 1.5.2, shoving them into a sub-package (Distutils.Fixed), and then just loading the correct ones on startup? I don't think there's anything in the 1.5.2 library
Christopher, Good idea, but not quite there yet. It can't be a sub-package; they have to actually be on the standard sys.path. In Grail, some versions have included a directory "pythonlib" that included updates to standard modules. pythonlib was then added to sys.path before everything else (along with the other Grail-specific directories). Perhaps the best approach is to add a directory pythonlib within distutils, and distutils/__init__ can add it to sys.path: import os, sys pythonlib = os.path.join(os.path.dirname(__file__), "pythonlib") if os.path.isdir(pythonlib): sys.path.insert(0, pythonlib) This ensures that other standard modules that use the modules we're providing updates for get the fixed versions. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives
The alternative is to allow (at least) 1.5.1, and provide reimplementations of the buggy functions so that Distutils can work on pre-1.5.2 Pythons.
Maybe I am overly conservative, but I have hesitated for quite a while before making my code require 1.5! Keep in mind that our target group includes users who don't care about Python. They may simply want to use an application written in Python. Most people I know (computational scientists) use Unix systems that were set up two to four years ago and then never updated. I am sure there are still many systems with Python 1.4 out there. So my vote is for supporting at least 1.5, and if possible even 1.4. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen writes:
So my vote is for supporting at least 1.5, and if possible even 1.4.
I think the approaches we've discussed allow supporting versions quite a ways back, as long as the bugs we need to work around are in Python modules, and not in C modules. The biggest issues for older versions will probably show up in testing -- this becomes even more important. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives
Quoth Konrad Hinsen, on 10 March 1999:
Keep in mind that our target group includes users who don't care about Python. They may simply want to use an application written in Python. Most people I know (computational scientists) use Unix systems that were set up two to four years ago and then never updated. I am sure there are still many systems with Python 1.4 out there.
Absolutely. For example, my old job was at a scientific lab with a lot of interest in scripting. We used MATLAB, relied heavily on Perl, and dabbled (once, long ago) in Python. If I login there today: % python Python 1.0.3 (Aug 14 1994) Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
Blast from the past, anyone? ;-)
So my vote is for supporting at least 1.5, and if possible even 1.4.
Seems to me that the three most important language/library features in 1.5 were: * packages * re and r'' * class-based exceptions Of course, those are the three that I use a lot, so I may be biased. And Distutils relies on all of them. I could probably hack it so that re and class-based exceptions are only used under 1.5, but I'm not sure if I could sweep the heavily "packagized" nature of the Distutils under the rug. Would we have to resurrect use of the 'ni' module in the 1.4 case? Would that be painful? I think for the initial versions, I'll strive for compatibility with 1.5, 1.5.1, and 1.5.2. Switching the exception model and how the Distutils are organized on a high-level (1.5-style packages vs. 'ni') should be doable without extensive, low-level changes to the code. That leaves regular expressions; I'll try to minimize their use with a view to making them completely optional. (Eg. if version is 1.4, don't even do this regex-based sanity check. If a regex is required to parse some string, then I'll have to figure out how to do it otherwise. So far that's what I've done.) Any other language features I should be wary of avoiding? I am willing to consider supporting 1.4 if it won't be too much trouble, but not in the initial phases -- we should probably worry about that when it comes time to make a public release in a few months. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward writes:
Seems to me that the three most important language/library features in 1.5 were: * packages
Try "import ni" in the script for older Pythons. This worked fine for Grail until other aspects of the code required 1.5. Make sure the __init__.py files contain nothing by comments and docstrings.
* re and r''
Use regex and more backslashes. These are convenient, but not required for functionality.
* class-based exceptions
Not required for functionality.
re and class-based exceptions are only used under 1.5, but I'm not sure if I could sweep the heavily "packagized" nature of the Distutils under the rug. Would we have to resurrect use of the 'ni' module in the 1.4 case? Would that be painful?
import sys; if sys.version[:3] < "1.5": import ni
Any other language features I should be wary of avoiding? I am willing to consider supporting 1.4 if it won't be too much trouble, but not in the initial phases -- we should probably worry about that when it comes time to make a public release in a few months.
Don't use assert; write a function that does the same thing. This is trivial, but you're welcome to steal the Assert module from Grail if it's too much typing. ;-) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives
participants (4)
-
Christopher Petrilli -
Fred L. Drake -
Greg Ward -
Konrad Hinsen