A way to accommodate laguage changes

[Stephen Horne]

On Tue, 24 Jul 2001 10:37:13 -0700, Chris Barker
<chrishbarker at home.net> wrote:

>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!

I saw it and I liked it. I didn't have much to add to it, though.

A version header - like the 'from __past__' suggestion and others -
would allow a script to explicitly state the syntax and semantics it
needs and therefore the possibility of either supporting multiple
feature-and-semantics variants - or of simply rejecting the hopelessly
out-of-date - becomes easy.

The 'from __past__' idea specifically requests the particular facility
it might need. The trouble being that, back in the past when the
programmer wrote the script the appropriate 'from __past__'
declaration did not exist.

The 'version' header does not require knowledge of which facilities
have changed (or might change in a few versions time), and by
inferring version <= 2.1 where the header is not present (there can't
be many 2.2 apps in the field ATM ;-) can even reject apps where the
author didn't realise some facility would break when he released it.

The worry with the version header is that Python would complain about
every file on every minor version update. People would just get into
the habit of greping and 'fixing' every single file when they updated
Python, which would defeat the object.

Version marking with the major version only would probably be
workable, however.

A more detailed system - such as specifying versions for each type of
functionality used - could become too annoying and fiddly to work out.

Marking code is not a simple issue. I think something useful could be
constructed from these, but any scheme would have its -ve side.