New PEP: The directive statement

[Bruce Sass]

On 22 Mar 2001, Martin von Loewis wrote:
> Bruce Sass <bsass at freenet.edmonton.ab.ca> writes:
>
> > Why was (something along the lines of)...
> >
> > use:
> >     __future__.nested_scopes
> [...]
> > ...rejected?
>
> It was not rejected - it simply was not proposed by anybody. I'd feel
> that a block structure for "settings" is overkill; it's not that you'd
> activate dozens of features that way.

I'm generalizing a little more than either the __future__ or directive
proposals.  I see wanting to `test beta features out on the general
population' as a subclass of the `is that feature/module/etc. available'
problem faced when writing a program.

For example, I'd rather do...

use:
    new_math.//
    result = new_math_based_function()
except NewMathError:
    result = old_math_based_function()

...and have the compiler use the appropriate source depending on what
the interpreter can handle, rather than do a check of the
"sys.version"[1] or try to catch a run-time exception.

I'd also rather do...

use:
    __future__.nested_scopes

...or even...

use: nested_scopes

...than...

from __future__ import nested_scopes

...or...

directive nested_scopes

...but for purely aesthetic reasons.

The way I see it there is no reason for "use: something.whatever" to
have a specific interpretation.  e.g., "use: nested_scopes" could be a
compile time switch, "use: new_math.//" acts like a preprocessor.

"use:" looks like an intuitive way to handle both (and any number of
different) types of extras to the language or its implementation, and
even be a general wy of dealing with coding for multiple versions of
the language.


> In any case, if you really want to see such syntax, draft a few lines
> of how exactly that should work, and I put them into my text (or you
> can write your own PEP).

I don't know enough about Python's internals to author a PEP[2], but
would be open to working with someone who did (so that the few lines
produced could be implemented without rewriting all of Python, etc.)


- Bruce


[1] What I'm talking about is the difference between each program
needing to know what versions of Python support which features, and
telling the compiler what to do if it (or the interpreter) can not
handle a certain feature (or a specific module, or package, is
unavailable).

[2] If I did, the "motivation" would be: "from __future__ import" is
confusing, "directive" looks messy, neither addresses things from the
programmer's perspective...