Why "from __future__" stinks; a counter-offer

[Tim Peters]

[Jason Orendorff]
> 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.

Good -- then it will stick out <0.5 wink>.  Double double-underscore names
are intended to "stick out", btw, and future_statements are intended to be
temporary.  In that sense, the uglier they are, the more incentive to get rid
of them ASAP.

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

If they don't use Python, I don't know why you'd bother to mention this to
them regardless of spelling.

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

At the moment, __future__.py contains only one entry, which refers to 2.2
final.  Sounds like the future to me.

> 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.

I agree that would be better.  Over time, though, it becomes less
interesting, as people move to more recent releases (which will raise
exceptions at compile-time for future_statements they can't satisfy).

> Lastly and most importantly, it's not too late to do
> something saner.

Unclear, although in the absence of a competing PEP it's certain to remain as
it is, and the last 2.1 beta release is scheduled for this coming Friday (as
noted in PEP 226).

> I agree it's desirable to have the code itself advertise that it
> uses a certain nascent feature.

Since syntax and/or semantics change in the presence of a future_statement,
it's *mandatory* that modules desiring the new behavior explicitly say so --
"desirable" has nothing to do with it.

> So, what if we do something like this:
>
>   1. Pick a name.  Suggestions follow:
>          require
>          using
>          pragma
>          this_code_uses
>          feature
> ...

Did you read Martin's messages on this?  He picked "directive", and submitted
a patch to implement it (or some part of it).  But he didn't write a PEP, so
you'll have to search c.l.py and SourceForge for the relevant bits.  He had
in mind a more general facility, and in particular wants to specify
source-file character encodings someday; I actively want not to conflate
future_statements with "general directives" (although "directive future xxx"
might be OK -- alas, without a PEP, it's a non-starter).

BTW, from the names you suggested, I have to guess that you think a
future_statement is for an "optional feature".  It is not:  it's for an
incompatible language change that will become *mandatory* in a future release
(and there's no going back then).  future_statements are a temporary aid for
use during a transition period.  "require", "using", "this_code_uses" and
"feature" all send a wrong message in that respect.  "pragma" is
inappropriate because future_statements are about syntax and semantics, not
pragmatics.

patiently-awaiting-the-end-of-the-world-ly y'rs  - tim