Why "from __future__" stinks; a counter-offer

[James_Althoff at i2.com]

If folks are getting worked up about the name __future__  (seems fine to
me), perhaps __roadmap__ would be another possibility?

Jim




                                                                                                                   
                    "Tim Peters"                                                                                   
                    <tim_one at email.msn        To:     <python-list at python.org>                                     
                    .com>                     cc:                                                                  
                    Sent by:                  Subject:     RE: Why "from __future__" stinks; a counter-offer       
                    python-list-admin@                                                                             
                    python.org                                                                                     
                                                                                                                   
                                                                                                                   
                    03/18/01 01:04 PM                                                                              
                                                                                                                   
                                                                                                                   




[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


--
http://mail.python.org/mailman/listinfo/python-list