A counter-counter-proposal for PEP 236: #pragma( nested_scopes)

[Stefan Franke]

On Sat, 3 Mar 2001 16:59:01 -0500, "Tim Peters" <tim.one at home.com> wrote:

>last-msg-from-me-on-this-until-there's-a-pep-ly y'rs  - tim
>

Hmm. Propably somewhat late to reply to this thread, but it's hard to keep up
with c.l.py these days...

I thought a little bit about the "from __future__ import nested_scopes" stmt, 
and what I found most disturbing is that it breaks the "explicit is better than 
implicit" rule. Wasn't it you who...?

IMO the fact that we have a real module __future__ in the filesystem that is 
*really* imported, but silently triggers some additional magic, is not a feature
but rather dangerous.

Consider a newbie who read one of the many pre-2.1 books or a Python
veteran who hasn't used the language for a while. What would they do
if they see the import statement?

They would propably see the __future__ module in the filesystem, notice 
that a tuple was imported and that's it! 
In the best case some comments around the definitions in the __future__ 
module are recognized that explain the additional magic.

But since the whole process is implicit, they wouldn't possibly ever dream up 
that there might be something special about it.

> "__future__" screams "Deep Magic" because of the double
> double-underscores;

I don't think so. We already have __init__.py modules all over. IMO they 
signal that the files are used by Python's runtime system, but not
necessarily "black magic".

 * * *

(Now for my own little €0.02 proposal..)

Why not make __future__ an additional builtin function? Double underscore
names are reserved anyway, so we don't have the additional statement 
problem.
Ok, we still have the magic here, but the first thing I guess my imaginary 
newbies/veterans would do is to look up the behaviour of the 

  __future__("nested_scopes") 

call in the docs, since it is something unknown, and it must be built in (it
appears before any other statement or imports).

Maybe it's just my personal sense, but I find this explicit enough to make
someone looking into the docs, whereas the implicit import variant looks 
normal enough to be taken for a standard case.

Of course __future__ might not be the best name for the function(*). Note
that we get the other benefits too:

- Like before, the __future__("nested_scopes") call has to appear among 
  the first statements of a module, otherwise an exception is raised
- The version tuple could be the return value
- Additional parameters are possible
- There's no syntax change involved

from __future__ import *-ly y'rs
Stefan


[* Perhaps the name is everything: 

from __RTFM_immediately_when_you_see_this__ \
import stackless_behaviour_now

might be just as effective..]