Backwards emulation rather than backwards compatibility?

[Chris Liechti]

"John Roth" <johnroth at ameritech.net> wrote in 
news:uf06o3f6tu8ud3 at news.supernews.com:
> "Martin v. Loewis" <martin at v.loewis.de> wrote in message
> news:m3it5cp8hj.fsf at mira.informatik.hu-berlin.de...
>> Antaeus Feldspar <feldspar at ix.netcom.com> writes:
>>
>> > Could the python interpreter be equipped with a mode that would
> allow
>> > it to emulate past interpreters?
>>
>> No, that won't be possible. It is easy enough to install multiple
>> versions of the interpreter, though.
>>
>> Regards,
>> Martin
> 
> Oh, come on now. Anything is possible, the question is
> whether it is worth doing and (this being a volunteer effort)
> whether anyone wants to do it.

what ever you define as "possible" - if the result is something so 
complicated that nobody realy knows whats going on, would you say that it 
is a favorable target?

> Frankly, I think it's an excellent idea, although it would
> have a cost.
> 
> To delimit the debate: either a specific statement at the
> front of the module "Requires 2.1" or the code in the
> compiled module indicates the language level needed.

no it would require a statement "must not have newer features than 2.1"
it's the new features in the future that cause the problems.
(for me "requires" means "at least", "that or a newer one")

e.g. if you just say that some script requires 2.1 you can still use 
"yield" as a name but it will fail in 2.3 becuase that name becomes a 
keyword. so you effectively need to specify that the scripts needs 2.1 but 
not newer, not older.
and this is best done using "#!/usr/bin/env python2.1"

no new invention needed, its already there...

chris

-- 
Chris <cliechti at gmx.net>