On Mon, May 18, 2015 at 11:32 PM, Joao S. O. Bueno
Indeed - importing as NOP would surely be broken -
The nice fix would be to be able to do from __future__ import jaberwock
and have a plain "ImportError" that could be catched.
Indeed. Though I'm not sure what a correctly-spelled "from __future__ import jabberwock" would do; exceptions already "burble" up the call stack until they meet "the clause that catch[es]" them. :)
But, as Chris Angelico put it, it might be complicated. Manually testing sys.version seens to be the way to go Because, even if making __future__ imports raise ImportError, taht would also only be available from Py 3.5/3.6 onwards.
(Otherwise from __future__ import from__future__import_ImportError seens fun enough to actually be created)
Heh. Though there's no particular reason to guard this with a future directive; if the behaviour were to be changed, it could just be done immediately - you wouldn't need a couple of minor versions' notice that something's going to stop raising errors. The way to make this work would be two-fold. Firstly, an incorrect __future__ directive would have to no longer be a SyntaxError; and secondly, __future__ directives would have to be permitted after a try statement (currently, they're not allowed to follow anything, so the 'try' would have to be special-cased to be allowed in). With those two changes, though, the failing of a __future__ directive would now become a failure at the (usually-ignored) run-time import - the regular action of "from module import name" would fail when it tries to import something that isn't present in the module. As a side effect, some specific directives would become legal no-ops: from __future__ import CO_FUTURE_PRINT_FUNCTION from __future__ import __builtins__ # etc I don't see this as a problem, given that the point of the SyntaxError is to catch either outright spelling errors or version issues (eg trying to use "from __future__ import print_function" in Python 2.5), both of which will still raise ImportError. The question is, how often is it actually useful to import a module and ignore a __future__ directive? Going through all_feature_names: nested_scopes: No idea; I think code is legal with or without it. generators: Using "yield" as a keyword will fail division: Yes, this one would work absolute_import: This would work with_statement: Any actual use of 'with' will bomb out print_function: Might work if you restrict yourself unicode_literals: Possibly would work, but ow, big confusion barry_as_FLUFL: No idea, give it a try! generator_stop: Yes, would work. So three of them would definitely work (in the sense that code is syntactically correct in both forms), and you could cope in some way with an except block; print_function would work as long as you build your code with that in mind (but if you're doing that anyway, just drop the future directive); and unicode_literals *might* work, maybe. The rest? If you're using the future directive, it's because you want the new keyword, which means you're going to be using it. If the future directive isn't recognized, you're getting syntax errors elsewhere, so there's no opportunity to try/except the problem away. What will the future of Python future directives be like? Most likely a similarly mixed bag, so this is a feature that could potentially have very little value. Is it worth downgrading an instant SyntaxError to a run-time ImportError to allow a narrow use-case? ChrisA