PEP 236 states that the intention of the proposed feature is to allow modules "to request that the code in module M use the new syntax or semantics in the current release C".
It achieves this by introducing a new statement, the future_statement. This looks like an import statement, but isn't. The PEP author admits that 'overloading "import" does suck'. I agree (not surprisingly, since Tim added this QA item after we discussed it in email).
It also says "But if we introduce a new keyword, that in itself would break old code". Here I disagree, and I propose patch 404997 as an alternative (https://sourceforge.net/tracker/index.php?func=detail&aid=404997&gro...)
<specification section="Alternative Solution"> In essence, with that patch, you would write
directive nested_scopes
instead of
from __future__ import nested_scopes
This looks like as it would add a new keyword directive, and thus break code that uses "directive" as an identifier, but it doesn't. In this release, "directive" is only a keyword if it is the first keyword in a file (i.e. potentially after a doc string, but not after any other keyword). So
class directive: def __init__(self, directive): self.directive = directive
continues to work as it did in previous releases (it does not even produce a warning, but could if desired). Only when you do
directive nested_scopes directive braces class directive: def __init__(self, directive): self.directive = directive
you get a syntax error, since "directive" is then a keyword in that module.
The directive statement has a similar syntax to the C #pragma "statement", in that each directive has a name and an optional argument. The choice of the keyword "directive" is somewhat arbitrary; it was deliberately not "pragma", since that implies an implementation-defined semantics (which directive does not have).
In terms of backwards compatibility, it behaves similar to "from __future__ import ...": older releases will give a SyntaxError for the directive syntax (instead of an ImportError, which a __future__ import will give). "Unknown" directives will also give a SyntaxError, similar to the ImportError from the __future__ import. </specification>
Please let me know what you think. If you think this should be written down in a PEP, I'd request that the specification above is added into PEP 236.
Regards, Martin
[Martin v. Loewis]
... If you think this should be written down in a PEP,
Yes.
I'd request that the specification above is added into PEP 236.
No -- PEP 236 is not a general directive PEP, no matter how much that what you *want* is a general directive PEP. I'll add a Q/A pair to 236 about why it's not a general directive PEP, but that's it. PEP 236 stands on its own for what it's designed for; your PEP should stand on its own for what *it's* designed for (which isn't nested_scopes et alia, it's character encodings).
(BTW, there is no patch attached to patch 404997 -- see other recent msgs about people having problems uploading files to SF; maybe you could just put a patch URL in a comment now?]
Martin, this looks nice, but where's the patch? (Not in the patch mgr.)
We're planning the b1 release for Friday -- in two days. We need some time for our code base to stabilize.
There's one downside to the "directive" syntax: other tools that parse Python will have to be adapted. The __future__ hack doesn't need that.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido wrote:
There's one downside to the "directive" syntax: other tools that parse Python will have to be adapted. The __future__ hack doesn't need that.
also:
- "from __future__" gives a clear indication that you're using a non-standard feature. "directive" is too generic.
- everyone knows how to mentally parse from-import state- ments, and that they may have side effects. nobody knows what "directive" does.
- pragmas suck. we need much more discussion (and calender time) before adding a pragma-like directive to Python.
- "from __future__" makes me smile. "directive" doesn't.
-1, for now.
Cheers /F