A counter-proposal to __future__ in PEP 236

[Martin von Loewis]

"Fredrik Lundh" <fredrik at pythonware.com> writes:

> > Even though this looks like an import statement, it is not: instead,
> > it changes the meaning of variable binding in the presence of nested
> > functions.
> 
> Really?  I'd say it imports an alternate compiler, and activates it
> for all modules that happens to contain a from __future__ state-
> ment.

Exactly. That makes it not to be an import statement; an import
statement essentially calles __import__, and you cannot arrange it to
import compilers.

> > directive nested_scopes
> 
> Note that we're not talking optional standard features here, we're
> talking untested experimental stuff, on a scale too large to handle
> in an ordinary prerelease cycle.

I understand that. Then let's call it 

experimental nested_scopes

or

directive experimental nested_scopes

> __future__ stuff may go away or change, if they turn out to be
> a bad idea.  If you're easily confused, you shouldn't use them at
> all.

The specific thing being "imported" (e.g. nested scopes) may go away
or change. I read PEP 236 to mean that __future__ is here to stay.

> But with your proposal, you make them look like optional features.

Is the the keyword that makes them look like that? My proposal is open
to picking a different keyword.

> That isn't just a bad idea, it makes Python look bad too.

Why is that?

> Smells like hypergeneralization to me (which is a worse sin than
> premature optimization).  Source code encodings and experimental
> compiler features are two entirely different things.

They are similar as source code encoding might also be an experimental
feature first. They are also similar 

> > In this implementation, directive is only considered as a keyword if
> > it appears at the beginning of the module
> 
> And you think from __future__ is a hack?  Gimme a break.

It's a transitional feature to introduce the keyword directive (or
whatever it is called). At some point, directive will be a proper
keyword, at which time it won't be a hack anymore. At that time,
future statements will still be spelled "from __future__ import
case_insensitive", and it will still be a hack.

There are two unrelated issues here: smooth introduction of nested
scopes, and smooth introduction of per-module semantical
changes. Apparently, there is no clear way of doing that, so it should
be done in a way that causes least confusion and least hackery.

Regards,
Martin