A way to accommodate laguage changes

[Chris Barker]

James Logajan wrote:
 > Chris Barker wrote:
> > pain it is likely to cause by:
> >    A) Breaking old code
> >    B) Making it very difficult to write code that can run on old and new
> > version of the interpreter.
> >
> > It seems that since (3) is the big stumbling block, perhaps we need to
> > focus our intentions on how to make not only this change, but other
> > potential changes less painful. It's too late now, but ideally, Python
>                                   ^^^^^^^^^^^^^^^^^
> 
> Not to be abrupt, but if it is too late now, why bother mentioning it?

Poorly worded. What I meant was that it is too late to require a version
header in old code. It is not too late to require it in new code that
uses new features of the language. It could be assumed that not having a
version header means that the code is designed for version <= 2.1.

> I effectively stopped considering Python for new projects as of last night.
> I can't read Guido's mind, I don't know what other code-breaking changes he
> might be considering. I'm not sure he even knows. 

That's why I have proposed a method of mitgating the problem, both for
this example, and any others. Frankly, the one downside I see is that
making it easier to accomodate incompatable changes makes it more likely
that they will occur, and I think that such changes should be VERY rare.
(I'll comment elsewhere on whether I think the integer division isssue
is an example of one that should be done).

Terry Reedy wrote:
> This problem, though worse in a way with the division change, is
> generic to all language changes.  To run newly written code under old
> versions of the interpreter, you have to eschew *all* features added
> after the oldest version you want to support.  For 1.5.2, this means
> list comprehensions, augmented assignments, nested scopes, iterators,
> generators, type-class unification features, and what ever else is
> next added.

Well of course. There is nothing to be done about that. I fyou dont'
want the new features, don't use them, if you do, upgrade your Python
installation. So far, things were added, not changed, so old code would
run unchanged on new interpreters. My proposal allows that to still be
the case.

Cold someone please comment on my proposal (adding a version header of
some sort to all new files, and having backward compatable modes in all
new interpreters)? I'm sure it's full of holes, so I'd like to know what
they are!

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------