On Monday 08 April 2002 07:54, Barry A. Warsaw wrote:
AM> It would help to some degree if the "stable" releases could be AM> shown to have SOME kind of enhancement. Not as much as if AM> language changes which did not break existing correct code AM> could also be there, but some. Modules such as email are a AM> big part of the draw of 2.2, for example (not quite as big as AM> language-level enhancements, but big).
And of course, I spend a non-trivial amount of effort to maintain a separate email package that is compatible with Python 2.1 and Python 2.2. But I consciously gave up Python 2.0 (or earlier) support because it became obvious to me that I wanted /some/ of the newer features.
But that's really difficult, considering it means I have to keep two cvs repositories in sync (and yes, I've got a bunch of changes that need merging back into Python 2.3).
How does this amount of effort (keeping two CVS repositories in sync) compare to maintaining just one tree but with "feature-test macros" as one might try to do in C? In other words, how much help would it be if (for example) Python's compiler optimized away tests of the form, e.g., if __version__ > ( 2, 2 ) : as it does now with -O for "if __debug__:" but even more deeply (so even some "syntax errors" in the optimized-away conditional would be OK -- catering for future syntax changes at the add-a-keyword level, e.g.)?
Maybe the obfuscated-with-version-tests merged source would be too hard to maintain -- and maybe not, so I'm quite curious about what your experience suggests here. Intuitively, it might seem a version test could perhaps help two or more versions be alive at the same time, but I know of so much controversy over C's #if (mostly, IMHO, because of its over-use) that I wonder.