Backwards compatibility [was Re: is parameter an iterable?]

[Steven D'Aprano]

Fredrik Lundh wrote:

> Steven D'Aprano wrote:
> 
> 
>>Alas and alack, I have to write code which is backwards
>>compatible with older versions of Python:

[snip]

>>What should I do when I can't rely on functions that
>>don't exist in older versions of Python?
> 
> 
> python 2.1 doesn't support iterators, so that question doesn't
> make much sense.

The _question_ doesn't make much sense? I could 
understand you saying that backwards-compatibility is 
"not important [to me]" but to say that the very 
question of how to maintain backwards compatibility 
makes little sense is a bit extreme, don't you think?

Fredrik, I bow to your superior knowledge about Python, 
no sarcasm intended, and I've learnt a lot from your 
posts, thank you. But this is not one of your shining 
moments. Your attitude was utterly dismissive: the 
"right way" to solve the problem of recognising 
iterables was to use iter, and that's all that needs to 
be said.

The problem of how to recognise iterables did not come 
into existence with version 2.2, and backwards 
compatibility is sometimes a real requirement. A few 
months back I had to mangle some Py2.4 code so that it 
would run under version 2.0, and wasn't that fun.


> if you want to write code that runs under 2.1, you have to write
> your code in terms of what 2.1 supports.

Do you think I don't know this?

I never imagined for an instant that Python 2.1 would 
somehow magically be able to use features that didn't 
exist in Python 2.1. But then it wasn't me saying that 
there was nothing to discuss, the "right way" is to use 
iter(), end of story.

If I have to write code that can't rely on iter() 
existing in the language, what should I do?

Are there practical idioms for solving the metaproblem 
"solve problem X using the latest features where 
available, otherwise fall back on older, less powerful 
features"?

For instance, perhaps I might do this:

try:
     built_in_feature
except NameError:
     # fall back on a work-around
     from backwards_compatibility import \
     feature as built_in_feature

Do people do this or is it a bad idea?

Are there other techniques to use? Obviously refusing 
to run is a solution (for some meaning of "solution"), 
it may even be a practical solution for some cases, but 
is it the only one?

In the specific case of iter(), are there good 
alternative ways of detecting an iterable without 
consuming it?



-- 
Steven.