A counter-proposal to __future__ in PEP 236

[Tim Peters]

[Joshua Marshall]
> ...
> Note that it doesn't need to be implemented this way.  Currently,
>
>   directive foo
>
> is a syntax error.  Meaning can be assigned to this syntax without
> breaking any existing code--it is unambiguous.

[Tim]
> You should study Python's parser before getting too optimistic about that
> <wink>.

[back to Joshua]
> So anybody care to post an example of how this can be ambiguous (in
> context) so I don't need to go study Python's parser...?

It's not a question of ambiguity.  You really need to study the parser!  Some
changes are easy, others are hard, due to the way the parser is implemented.
Make "directive" a keyword and it's trivial, because then it can be captured
directly by a grammar production.  It's not possible-- in Python's
parser --to make the identifier "directive" a keyword in some contexts but
not others; if it's not a keyword, it would have to be expressed in terms of
a generic sequence-of-NAME production followed by post-processing.

You also have to consider the parsers in tools, from the Emacs python-mode
thru whatever the heck PythonWorks uses.  Then also the tools building on the
parser module's form of parse trees, which won't even have a case now for
*considering* that "sequence of NAME" is a possible construct.  Unless
"directive" is a keyword, it's a pain in the ass for all of them.

Doesn't mean it can't be hacked, but it's ugly, and you have to get a lot of
different people to sign up to do all that hacking.

"possible"-is-necessary-not-sufficient-ly y'rs  - tim