Why "from __future__" stinks; a counter-offer

[Jason Orendorff]

Reply-to: sender

Okay, nested scopes are a good idea.  Having the feature
"disabled by default" in 2.1 is a good idea.  But this
"from __future__" stuff isn't so hot.

First, it's ugly.

Second, owing mostly to its ugliness, it will be
*really* embarrassing to try and explain this to my
(non-Python-bitten) friends.

Third, it's extremely silly to have a module named
"__future__" that describes only the present and the past.

Fourth, Python 2.0 and earlier report an
    ImportError: No module named __future__
when they encounter a future_statement.  Surely a
compiler error, even a SyntaxError, would be more
appropriate and less confusing.

Lastly and most importantly, it's not too late to do
something saner.  I agree it's desirable to have the
code itself advertise that it uses a certain nascent
feature.  So, what if we do something like this:

  1. Pick a name.  Suggestions follow:
         require
         using
         pragma
         this_code_uses
         feature

  2. Add a new statement to Python's grammar:
         require <name> [, <name>]*
     Or:
         import feature <name>
     It's allowed in the places where a
     "future_statement" *would* be allowed, if they
     didn't *suck* so much.

  3. In Python 2.1, the chosen name is not a
     keyword.  This way, the feature does not break
     any old code.

It could be argued that adding a new statement that
uses a pseudo-keyword is ugly, but it's certainly less
ugly than "from __future__", and more intuitive, and
less humiliating to explain.  And there's a precedent
(the pseudo-keyword "as" in import statements.)

And there has to be a limit to what we'll put up with
to avoid adding a new keyword (or pseudo-keyword) to
the language.

I'll be happy to implement, if there's any interest.

-- 
Jason Orendorff
Please reply to jorendorff at zoho.com .