title: How to gracefully deal with failed future feature (__future__) imports due to old interpreter version?
body: <p>How do you gracefully handle failed future feature imports? If a user is running using Python 2.5 and the first statement in my module is:</p>
  
  <pre><code>from __future__ import print_function
  </code></pre>
  
  <p>Compiling this module for Python 2.5 will fail with a:</p>
  
  <pre><code>  File "__init__.py", line 1
      from __future__ import print_function
  SyntaxError: future feature print_function is not defined
  </code></pre>
  
  <p>I'd like to inform the user that they need to rerun the program with Python >= 2.6 and maybe provide some instructions on how to do so. However, to quote <a href="http://www.python.org/dev/peps/pep-0236/" rel="nofollow noreferrer">PEP 236</a>:</p>
  
  <blockquote>
    <p>The only lines that can appear before
    a future_statement are:</p>
    
    <ul>
    <li>The module docstring (if any).</li>
    <li>Comments.</li>
    <li>Blank lines.</li>
    <li>Other future_statements.</li>
    </ul>
  </blockquote>
  
  <p>So I can't do something like:</p>
  
  <pre><code>import __future__
  
  if hasattr(__future__, 'print_function'):
      from __future__ import print_function
  else:
      raise ImportError('Python &gt;= 2.6 is required')
  </code></pre>
  
  <p>Because it yields:</p>
  
  <pre><code>  File "__init__.py", line 4
      from __future__ import print_function
  SyntaxError: from __future__ imports must occur at the beginning of the file
  </code></pre>
  
  <p>This snippet from the PEP seems to give hope of doing it inline:</p>
  
  <blockquote>
    <p>Q:  I want to wrap future_statements
    in try/except blocks, so I can use
    different code depending on which
    version of Python I'm running.  Why
    can't I?</p>
    
    <p>A:  Sorry!  try/except is a runtime
    feature; future_statements are
    primarily compile-time gimmicks, and
    your try/except happens long after the
    compiler is done.  That is, by the
    time you do try/except, the semantics
    in effect for the module are already a
    done deal.  Since the try/except
    wouldn't accomplish what it <em>looks</em>
    like it should accomplish, it's simply
    not allowed.  We also want to keep
    these special statements very easy to
    find and to recognize.</p>
    
    <p>Note that you <em>can</em> import __future__
    directly, and use the information in
    it, along with sys.version_info, to
    figure out where the release you're
    running under stands in relation to a
    given feature's status.</p>
  </blockquote>
  
  <p>Ideas?</p>