A counter-proposal to __future__ in PEP 236
n8gray at caltech.edu.is.my.e-mail.address
Fri Mar 2 03:29:08 CET 2001
Tim Peters wrote:
> [Martin von Loewis]
>> I personally consider this a confusing notation,
> I don't. "__future__" screams "Deep Magic" because of the double
> double-underscores; it *is* a perfectly vanilla import statement at runtime;
> the word "future" helpfully suggests temporality; it works with all existing
> tools today without change (so it's not confusing even the stupidest of them
> <0.1 wink>); and the imported nested_scopes name gets bound to release data
> that the importing code can examine; e.g.,
> from __future__ import nested_scopes
> assert nested_scopes > sys.version_info, "don't need this anymore"
>> and propose a different syntax, which would read
>> directive nested_scopes
> Which loses all of that. Incompatible language changes are a serious special
> case, and I don't want to see them swallowed up by some perfectly general
> mechanism that makes them impossible to distinguish visually from some
> innocuous request to, e.g., optimize for space instead of time.
I don't understand. "import" is a pretty general mechanism and the proposed
syntax is visually indistinguishable from a normal import except for the double-
double underbars. There's no reason Martin's proposal couldn't be tweaked:
assert nested_scopes.mandatory_release > sys.version_info \
"don't need this anymore"
with the same semantics (including importing the nested_scopes module) as your
proposal. Now you've got *both* the underbars *and* a new, scary keyword to warn
you that voodoo is being done. Call it "import_directive" to make the
"importish" nature more explicit (and reduce possibilities of code-breakage
because of "directive" being used as an identifier). And yes, definitely make
the new thing a keyword! No sense beating around the bush! If we're going to add
"magic imports" to the language, why not make them explicit?
As for the tool-breakage argument, the smart tools are going to have to be rewritten
to understand nested scopes anyhow. How hard is adding a new keyword relative to
that? And with "import_directive", the only change that needs to be made to the
stupid tools is a cut-and-paste of the "import" code.
>> The directive statement currently only supports activating nested
> I really dislike that
> directive nested_scopes
> *looks* exactly the same as
> directive favor_space
> That will add to confusion over time, not reduce it. Incompatible language
> changes have to kick you in the teeth.
from __future__ import nested_scopes
has the insidious effect of fooling the naive user into thinking he understands
what's going on when he actually doesn't! At least with import_directive or
directive the naive user is forced to look at the documentation. Once he does,
it's immediately clear that deep, dark things can be happening at compile time.
> Note that it's also not enough to allow just one or two optional tokens
> following "directive". One of the primary reasons no pragma facility ever
> got into Python is that in previous attempts nobody could agree on syntax
> that *was* sufficiently general (as a hint of the horrors you're signing up
> for, note that "optional static typing" fits-- because of the "optional"
> part --into a pragma framework; and once people realize that, they're going
> to hijack your proposal into an overly-generalized mess too).
Guilty as charged.
seems pretty clear to me.
If people are dead-opposed this becoming a general-purpose mechanism, call it
"import__future__" and only use it for the case PEP 236 addresses. I think our
objections are syntactic, not semantic. I can understand the advantages
that import semantics bring to the situation, but I hate to see a keyword with
clear, focussed meaning being extended for a single special situation.
California Institute of Technology
Computation and Neural Systems
n8gray <at> caltech <dot> edu
More information about the Python-list