A counter-proposal to __future__ in PEP 236

[Nathan Gray]

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[1] > 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:
	import_directive __future__.nested_scopes
	import sys
	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
>> scopes,
> 
> 
> I really dislike that
> 
>     directive nested_scopes
> 
> *looks* exactly the same as
> 
>     directive favor_space
>[snip]
> That will add to confusion over time, not reduce it.  Incompatible language
> changes have to kick you in the teeth.

But 
	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.
	import_directive static_typing
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.

-n8

-- 
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._
               Nathaniel Gray
     California Institute of Technology
      Computation and Neural Systems
       n8gray <at> caltech <dot> edu
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._