A counter-proposal to __future__ in PEP 236

[Michael Chermside]

On the topic of 
    from __future__ import foo
versus
    directive foo

I'm hearing two different messages here. On the one hand, I hear Martin saying
that the from __future__ syntax is ugly and misleading. On the other hand
I hear Tim saying that this is an incompatible language change, and requires
a different mechanism than what #pragma would offer. (Yes, I know other
people spoke too... I'm using Martin and Tim as representatives.)

So let me chime in.

On the first point, I have to agree with Martin. "from __future__ import foo"
is the sort of horrible ugliness which should never be seen outside of C++.
It is *NOT* an actual import statement, and it does *NOT* scream "black-magic"
-- just looks like another of those special "built-in" things; you know...
the functions __cmp__ and __import__ and the modules __builtin__ and 
__future__. But that's NOT what's happening here... we're doing something
VERY drastic (changing the language grammer) and the use of a special keyword,
like directive, may help signal that.

On the other hand, let's consider the second argument: don't get this mixed
up with pragmas. I realize that #pragma has been used for many different
purposes throughout it's colorful and inglorious history, but in MY mind
(you're free to disagree) the REAL purpose is "hints" like optimize-for-space
or inline-this-function, or I-won't-be-using-exec-so-don't-bother-including-
the-parser-when-you-compile. The thing that distinguishes these is that
they do NOT affect the behavior of the language... a "valid" program will
produce the same results whether the pragma is obeyed or ignored. In fact,
that's where the idea came from originally of putting it in comments...
because it didn't really help define the program, just provided pragmatic
hints for the compiler/interpreter.

Well, if THAT'S what we mean, then Martin's directive syntax will never do.
First and foremost, he requires the line to come at the beginning of the
file... which unreasonably restricts what you could do with it. If you wanted
to have favor_time and favor_space as options, you'd want to be able to turn
them on and off with finer granularity [debatable point]. In fact, the only
things that the directive keyword would really be useful for (in it's proposed 
form) are ones which affect an ENTIRE file... such as changes to the language
grammer (including keywords), or to the source syntax (eg latin-1). Including
pragmas is a separate issue.

So I'm coming out strongly in favor (+0.8) of the directive syntax. But in
doing so, I'd better point out the one place where I think the "from
__future__ import" syntax is better. Through the creation of an (empty)
"__future__" module, it becomes possible to write code that compiles and and
runs fine in pre-2.1 versions of python, which would choke up on encountering
the "directive" statement. But why? After all, if it USES the new feature
(nested scopes in this case, but it could be ANY new feature), then it
obviously isn't going to run in the pre-2.1 version. And if it doesn't use
the feature, then just don't put anything in! All post 2.0 versions of 
python could choose to fail when reading input with a directive statement
that they don't recognize (or maybe someone has a better behavior to suggest?).


How's-THAT-for-a-long-winded-and-strongly-opinionated-delurk-ly y'rs

-- Michael Chermside
   (who's too opinionated to be a good lurker anyhow)