[Python-Dev] one more restriction for from __future__ import ...

[Jeremy Hylton]

>>>>> "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