This is a very intentional change. Previously form feeds were handled very
poorly and sometimes where not counted as indentation. This obviously makes
sense. But at the same time indentation is very tricky to deal with (both for
editors and parso).
Especially in the diff parser this led to a lot of very weird issues. The
decision probably makes sense since:
1. Almost nobody uses form feeds in the first place.
2. People that use form feeds like Barry Warsaw often put a newline ater them.
(e.g Python's email.__init__)
3. If you write an editor you want to be able to identify a unicode character
with a clear line/column. This would not be the case if form feeds were just
ignored when counting.
Form feeds will still work in Jedi, will not cause parse errors and in general
you should be fine using them. It might just cause Jedi to count them as
indentation **if** you use it like '\f foo()'. This is however confusing for
most editors anyway. It leads to a weird display e.g. in VIM, even if it's
perfectly valid code in Python.
Since parso is a code analysis parser and not the languages parser I think it's
fine to ignore this edge case.
* Revision on assignment expression errors
* added rule for __debug__ (should be a keyword)
* reviewed error messages
* added new failing samples
* Adjustment upon Dave's review
* rewind several changes in assignment errors
* patched is_definition: command not found for assignment expressions
* patched Python 2 inconsistent error messages in test_python_errors.py: command not found
Under the old implementation,
```
outer: A [inner] B C
inner: B C [inner]
```
wouldn't get detected as the ambiguous grammar that it is, whereas
```
outer: A rest
rest: [inner] B C
inner: B C [inner]
```
would.
This would manifest itself as non-determinism in the DFA state
generation. See the discussion #62 on for a full explanation.
This modifies the ambiguity detection to work on a broader class of
issues, so it should now hopefully detect all cases where the given
grammar is ambiguous.
At some point, we could extend this logic to allow developers to
optionally set precedence of grammar productions, which could resolve
ambiguities, but that's not a strict requirement for parsing python.
Line continuation characters are valid inside of strings, but weren't
handled correctly in certain cases with f-strings, due to some small
tokenizer bugs.
This pull request to address those issues, and adds tests to validate
the new logic.
Dave Halter