Keith wrote:
> I was wondering if it might not be better (even possible) to merge the version
> compatibility into a switch, so people would optionally use a targetVersion
> flag or some-such.
>> Part of the difference between versions isn't simply language, it's outright
> bug corrections and compatibility with the base DLR, neh?
To a certain extent this is possible - for example it's not too hard to control
the parser based upon version and enable/disable new features. Also
controlling what methods are available and a small subset of behaviors is
pretty easy and we've done that in the past when we've had options which
enable a subset of the next version - 2.6 for example has a -X:Python30 option
which enables some 3.0 features / compatibility.
But to do this for an entire versions worth of features might be too many
random checks spread throughout the code base - usually there are plenty of
small changes in each release which we need to match. Things like deprecation
of various features, object.__new__/__init__ changed in 2.6, methods sometimes
get new arguments, and other little changes like that. Dealing with all of those
will be difficult and clutter up the code base making it more difficult to
maintain. In some cases we might need to add new features to fully emulate
the old version.
There's also the matter of our own compatibility at the .NET level - we
constantly need to balance advancing IronPython w/ maintaining compatibility
w/ existing apps. Would users upgrade a 2.0.3 app to 2.6 w/ 2.5 compat if
there are some breaking changes they need to deal with from the C# side? I
think a lot of the value in already released versions is their stability
so I'm not sure that having an evolving target which from the Python side
works mostly like the previous version has much value.
Not to mention that it's just plain more work and we already have plenty
to do :)