So what's wrong with __future__? (Was Re: Why "from __future__" stinks ...)

[Huaiyu Zhu]

I don't quite see what the complaint about __future__ is really about.  So
let me try to analyze a little bit.  Maybe this could encourage someone to
write a PEP to clarify.

What's wrong with import __future__?

1.  It is ugly.

Does this apply to syntax or semantics?

Syntax. 

But how?  It looks to me to be good on two accounts:
1. It stands out clearly as saying "magic".
2. It does not introduce new syntax or keyword.  Just a new module name.
How much better can you get if you want both?

Semantics.  It does not SHOUT "magic". A new keyword should be cleaner.

Not so.  Python __magic__ words have (at least) two effects:
1. automatic, like __init__.
2. side effect, like __setattr__, __builtin__.
The only magic of __future__ is side effects.

Does its semantics go beyond a regular module?  Well, yes.  But so what?  If
you redefine __setattr__, is its effect confined to itself?  If you redefine
operator.__add__, is its effect only felt when you call it explicitly?
Clearly you can complain that __setattr__ is not like any other method.  But
what would it look like if you introduce a new keyword in its place?


2. Future is the wrong word, because it concerns time.  A keyword like
__incompatible__ would convey meaning better.

Well, I can see both ways of thinking:

If you consider any given moment in time, its effect is indeed incompatible
change.  It's whether you want or don't want this change.

But if you consider the process of change, its effect is merely when a
change happens.  Your choice is only whether you want it now or in the
future.  (Maybe from __preview__ import *?)

I think Tim's intend is that anything that goes into __future__ will be
mandatory in some future version.  


3. It will introduce confusion about versions. 

This complaint will hold true no matter how you spell it.  The version info
in the __future__ module seems to minimize this problem.  In fact, if you
adopt the view that it is not an optional feature mechanism, but a time
travel mechanism, then the mechanism built in the PEP should be sufficient.

Now that's my rant about the complaints about __future__.  I'm even less
certain about what the proposed alternatives look like, and how they address
these problems.  Hopefully some proponents of the alternatives could write a
PEP along these lines?  I believe you will find the truth in Tim's comment
that any concrete proposal will attract lots of criticism.

If you are saying, __future__ is not good, but I do not have anything
substantially better, well then, what can be done?

Huaiyu