>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes: >> I would like to add another restriction: >> >> A future_statement must appear on a line by itself. It is not >> legal to combine a future_statement without any other statement >> using a semicolon. >> >> It would be a bear to implement error handling for cases like >> this: >> >> from __future__ import a; import b; from __future__ import c GvR> Really?!? Why? Isn't it straightforward to check that GvR> everything you encounter in a left-to-right leaf scan of the GvR> parse tree is either a future statement or a docstring until GvR> you encounter a non-future? It's not hard to find legal future statements. It's hard to find illegal ones. The pass to find future statements exits as soon as it finds something that isn't a doc string or a future. The symbol table pass detects illegal future statements by comparing the current line number against the line number of the last legal futre statement. If a mixture of legal and illegal future statements occurs on the same line, that test fails. If I want to be more precise, I can think of a couple of ways to figure out if a particular future statement occurs after the first non-import statement. Neither is particularly pretty because the parse tree is so deep by the time you get to the import statement. One possibility is to record the index of each small_stmt that occurs as a child of a simple_stmt in the symbol table. The future statement pass can record the offset of the first non-legal small_stmt when it occurs as part of an extend simple_stmt. The symbol table would also need to record the current index of each small_stmt. To implement this, I've got to touch a lot of code. The other possibility is to record the address for the first statement following the last legal future statement. The symbol table pass could test each node it visits and set a flag when this node is visited a second time. Any future statement found when the flag is set is an error. I'm concerned that it will be difficult to guarantee that this node is always checked, because the loop that walks the tree frequently dispatches to helper functions. I think each helper function would need to test. Do you have any other ideas? I haven't though about this for more than 20 minutes and was hoping to avoid more time invested on the matter. If it's a problem for Jython, though, we'll need to figure something out. Perhaps the effect of multiple future statements on a single line could be undefined, which would allow Python to raise an error and Jython to ignore the error. Not ideal, but expedient. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4