[Python-ideas] import fallback syntax

[Steven D'Aprano]

Chris Withers wrote:
> On 08/03/2012 11:06, Philip Jenvey wrote:
>>
>> It's been proposed before, you might want to read this old thread:
>>
>> http://mail.python.org/pipermail/python-dev/2008-January/075788.html
> 
> Heh, interesting that the same thing came up without me ever reading 
> that thread.
> 
> I think it's got legs, why do other people dislike the idea?

Because it adds more complexity to the language and parser for minimal benefit.

In my experience, the construct

try:
     import ham
except ImportError:
     import spam as ham


is not common enough or difficult enough to need special syntax for it. Not 
every special case needs special syntax, and if you don't like that it is a 
four-liner you can cut it down to a two-liner:

try:  import ham
except ImportError:  import spam as ham


Every new piece of syntax adds complexity to the language, increasing the 
overall burden of writing a piece of code. The try...except idiom is a general 
idiom that applies *everywhere* -- you try something, and if that fails, you 
do something else, regardless of the nature of the things you are trying. 
You're not limited to only catching ImportError and retrying the import, so it 
is easy to extend the idiom to variations such as:

try:
     from spam import x
except ImportError:
     # Must be an old version. Log it and fall back.
     log('using old version of spam')
     from spam import y


and here's a real piece of code from one of my libraries:


try:
     from math import isfinite
except ImportError:
     # Python 2.6 or older.
     try:
         from math import isnan, isinf
     except ImportError:
         # Python 2.5. Quick and dirty substitutes.
         def isnan(x):
             return x != x
         def isinf(x):
             return x - x != 0
     def isfinite(x):
         return not (isnan(x) or isinf(x))


"import x or y" doesn't have anywhere near the flexibility or power of a 
generalised try...except block because it is limited to a tiny subset of the 
actions you might want to take after catching ImportError.

Most special syntax for special cases doesn't add any new idioms for solving 
general problems, they just solve a single, narrowly defined, problem. Your 
suggestion is one of them: it can be used to solve two specific import problems:

import ham or spam as ham
from ham or spam import x

and I suppose it could even be extended, at the cost of even more complexity, 
to solve a third:

from ham or spam import x or y as z

but even so, it is still too narrowly focused on single idiom:

try:
     import some thing
except ImportError:
     import some other thing as a fallback


with no ability to do anything else. That makes it fall foul of the "Special 
cases" line from the Zen.

If the idiom being replaced was difficult enough, then maybe your suggestion 
would fly, but I don't believe it does. It's a pretty trivial transformation. 
Compare your suggestion with the "yield from" PEP, and you will see that while 
yield from initially seems trivial, there are in fact a whole lot of 
complicated special cases with coroutines that make it compelling. I don't 
believe that yours has anything like that.

Consequently, although I think your syntax is kinda cute, I don't think it 
adds enough benefit to be worth the change. My vote is +0.




-- 
Steven