Other situations like this (was RE: [Python-Dev] Nested scopes resolution -- you can breathe again!)

[Jeremy Hylton]

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

  TW> On Fri, Feb 23, 2001 at 06:00:59PM -0500, Jeremy Hylton wrote:
  >> Hmmmm...  I'm not yet sure how to deduce indent level 0 inside
  >> the parser.

  TW> Uhm, why are we adding that restriction anyway, if it's hard for
  TW> the parser/compiler to detect it ? I think I'd like to put them
  TW> in try/except or if/else clauses, for fully portable code. 

We want this to be a simple compiler directive, rather than something
that can be turned on or off at runtime.  If it were allowed inside an
if/else statement, the compiler, it would become something more like a
runtime flag.  It sounds like you want the feature to be enabled only
if the import is actually executed.  But that can't work for
compile-time directives, because the code has got to be compiled
before we find out if the statement is executed.

The restriction eliminates weird cases where it makes no sense to use
this feature.  Why try to invent a meaning for the nonsense code:

if 0:
    from __future__ import nested_scopes

  TW>                                                            While
  TW> on the subject, a way to distinguish between '__future__ not
  TW> found' and '__future__.feature not found', other than hardcoding
  TW> the minimal version might be nice.

There will definitely be a difference!

Presumably all versions of Python after and including 2.1 will know
about __future__.  In those cases, the compiler will complain if
feature is no defined.  The complaint can be fairly specific:
"__future__ feature curly_braces is not defined."

In Python 2.0 and earlier, you'll just get an ImportError: No module
named __future__.

I'm assuming the compiler won't need to know anything about the values
that are bound in __future__.  It will just check to see whether the
name is defined.

Jeremy