New PEP: The directive statement

[Huaiyu Zhu]

With the __future__ PEP, I envision there could also be things like

from __future__ import nested_scope
from __experimentatal__ import stackless
from __optional__ import static_type
from __mandatory__ import string_methods

New feature would migrate from __experimental__, to __future__, then to
either __optional__ or __mandatory__.  Things in __experimental__ are not
guaranteed to be there in later versions.  Things in __future__ will
definitely be there in a later version.  The __mandatory__ could be used to
make the intention about version requirement more explicit than __version__
would allow. (Someone asked about whether __future__ should be phased out in
later code.) The __optional__ could be used for permament optional features
that affect syntax.

So with this directive PEP, the parallel would be

directive transitional nested_scope
directive experimentatal stackless
directive optional static_type
directive mandatory string_methods

Is this correspondence correct?  (You may not agree on the need for other
directives, but I want to know if the keyword translations are correct.)

If so, I see two problems.
1. It introduces a new syntax while an existing syntax could be reused
   without much cost.
2. There is no place for version and documentation info.

So far as I can see, the impetus for directive keyword is that import is a
run time action, while the __future__ is a compile time declaration.  But is
it so far a stretch?  All Python __magic__ words go beyond normal meaning.
Defining __setattr__ will affect more than this method alone.  Having
__init__.py will cause other modules to be imported.  And so on.

If we look more broadly, in *nix, devices, processes, pipe and others are
also represented as files.  Would it better to assign special syntax to all
of them?

IMHO, reusing existing syntax is closer to Python than Perl, which
introduces new syntax for many things that are only slightly different.

Huaiyu