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.
--
http://mail.python.org/mailman/listinfo/python-list
