Backwards Compatibility of Python versions

[Philip Swartzleonard]

Paul Rubin || Mon 04 Feb 2002 01:05:15a:

> Jonathan Hogg <jonathan at onegoodidea.com> writes:
>> > So much for compatibility then.
>> 
>> I think I missed the beginning of this thread so I'm confused. Exactly
>> which new backwards incompatible feature of the recent Python versions
>> is it that is breaking people's old scripts?
>> 
>> So far I've seen complaints of 'x in somedict' which only affects
>> writing new code for the new Python interpreter, future division which
>> is not enabled yet by default, and the import __future__ mechanism,
>> which again is only meant to be called by new code on the new
>> interpreter. 
> 
> That's the problem--if I don't import future division, my code will
> break in the future, because the // operator isn't supported in the
> present.  But if I -DO- import future division, my code will break in
> the present, because current (2.1) and older (1.5) interpreters don't
> recognize the import statement.  (The most recently released version
> of Python is a 2.1 series release, so 2.1 is still current).
> 
> I don't see any reasonable way I can write code right now that uses
> division that works in both the current 2.1 (which doesn't support
> importing future division) and in forthcoming versions (where the
> semantics of the / operator will be incompatibly different).

Specifically add a decimal to a number or float() something if you're only 
using variables, and you will have the same behavior as the new division, 
which won't change between new and old division. Do this, and int() the 
result, and you will have the same effect as the new //, even when it is 
not available. 


-- 
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com