<p>不存在引起此限制的解析器问题。与Silvio Mayolo的回答相反,LL(1)解析器可以很好地解析无括号语法。在原始列表理解补丁的早期版本中,括号是可选的;它们只是为了使含义更清楚而被强制执行</p>
<p>引用2000年Guido van Rossum的话,在一篇<a href="https://mail.python.org/archives/list/python-dev@python.org/message/QXZTOKUJPBYJRNAX32EFI2YRX3RXNRIE/" rel="nofollow noreferrer">response</a>中,有人担心<code>[x, y for ...]</code>会导致解析器问题</p>
<blockquote>
<p>Don't worry. Greg Ewing had no problem expressing this in Python's
own grammar, which is about as restricted as parsers come. (It's
LL(1), which is equivalent to pure recursive descent with one
lookahead token, i.e. no backtracking.)</p>
<p>Here's Greg's grammar:</p>
<pre><code>atom: ... | '[' [testlist [list_iter]] ']' | ...
list_iter: list_for | list_if
list_for: 'for' exprlist 'in' testlist [list_iter]
list_if: 'if' test [list_iter]
</code></pre>
<p>Note that before, the list syntax was <code>'[' [testlist] ']'</code>. Let me
explain it in different terms:</p>
<p>The parser parses a series comma-separated expressions. Previously,
it was expecting <code>']'</code> as the sole possible token following this.
After the change, <code>'for'</code> is another possible following token. This
is no problem at all for any parser that knows how to parse matching
parentheses!</p>
<p>If you'd rather not support <code>[x, y for ...]</code> because it's ambiguous
(to the human reader, not to the parser!), we can change the grammar
to something like:</p>
<pre><code>'[' test [',' testlist | list_iter] ']'
</code></pre>
<p>(Note that <code>|</code> binds less than concatenation, and <code>[...]</code> means an
optional part.)</p>
</blockquote>
<p>另请参见线程中的<a href="https://mail.python.org/archives/list/python-dev@python.org/message/JR37WBPDZ4CXJRP4L7G3AEN5DUUWKHYE/" rel="nofollow noreferrer">next response</a>,Greg Ewing在其中运行</p>
<pre><code>>>> seq = [1,2,3,4,5]
>>> [x, x*2 for x in seq]
[(1, 2), (2, 4), (3, 6), (4, 8), (5, 10)]
</code></pre>
<p>在列表理解补丁的早期版本上,它工作得很好</p>