[Python-Dev] RE: [Idle-dev] Forward progress with full backward compatibility

[Tim Peters]

[Peter Funk]
> ...
> 2. What should the new Interpreter do, if he sees a source file without a
>    pragma defining the language level?

Python has tens of thousands of users now -- if it doesn't default to
"Python 1.5.2" (however that's spelled), approximately 79.681% of them will
scream.  Had the language done this earlier, it would have been much more
sellable to default to the current version.

However, a default is *just* "a default", and platform-appropriate config
mechanism (from Windows registry to cmdline flag) could be introduced to
change the default.

That is, 1.7 comes out and all my code runs fine without changing a thing.
Then I set a global config option to "pretend every module that doesn't say
otherwise has a 1.7 pragma in it", and run things again to see what breaks.
As part of the process of editing the files that need to be fixed, I can
take that natural opportunity to dump in a 1.7 pragma in the modules I've
changed, or a 1.6 pragma in the broken modules I can't (for whatever reason)
alter just yet.

Two pleasant minutes <wink> later, I'll have 6,834 .py files all saying
"1.7" at the top.  Hmm!  So when 1.8 comes out, not a one of them will use
any incompatible 1.8 features.  So I'll also need a global config option
that says "pretend every module has a 1.8 pragma in it, *regardless* of
whether it has some other pragma in it already".  But that will also screw
up the one .py file I forgot that had a 1.5.2 pragma in it.

Iterate this process a half dozen times, and I'm afraid the end result is
intractable.

Seems it would be much more tractable over the long haul to default to the
current version.  Then every incompatible change will require changing every
file that relied on the old behavior (to dump in a "no, I can't use the
current version's semantics" pragma) -- but that's the situation today too.
The difference is that the minimal change required to get unstuck would be
trivial.

A nice user (like me <wink>) would devote their life to keeping up with
incompatible changes, so would never ever have a version pragma in any file.

So I vote "default to current version" -- but, *wow*, that's going to be
hard to sell.

Tech note:  Python's front end is not structured today in such a way that
it's feasible to have the parser deal with a change in the set of keywords
keying off a pragma -- any given identifier today is either always or never
a keyword, and that choice is hardwired into the generated parse tables.
Not a reason to avoid starting this process with 1.6, just a reason to avoid
adding new keywords in 1.6 (it will take some real work to overcome the
front end's limitations here).

go-for-it!-ly y'rs  - tim