Re: [Python-ideas] if-syntax for regular for-loops
Besides consistency I think the one major benefit to for..if loops is that often you don't just save a line, but also an indentation level (whenever you use the if clause solely as a filter), which actually increases readability, specially when whatever you do within the loop is relatively long, with its own indentations. The syntax just feels natural. For example: for i in somelist if i.pending: <do stuff> I really don't see any disadvantage here. Vitor PS: moving the discussion from python-dev to python-ideas. ____________________________________________________________________________________ ¡Todo sobre Amor y Sexo! La guía completa para tu vida en Mujer de Hoy. http://mujerdehoy.telemundo.yahoo.com/
On Oct 10, 12:51 pm, Arnaud Delobelle <arno...@googlemail.com> wrote:
Not really. for_stmt: 'for' exprlist 'in' testlist ['if' or_test] ':' suite ['else' ':' suite] FWIW, I think this would be an entirely different discussion if someone did all of the work first (code+docs+test code), and THEN went to python-dev along with two or three examples from the standard library where the new syntax would *add* clarity. Side note: not to discourage anyone, but I happened to look at Lib/ pydoc.py and found several examples where, due to line-length, forcing the new syntax at every available opportunity would either substantially reduce clarity or be more or less pointless. Here are a couple cases so you can make up you own mind. #1 original: for ext in ('.py', '.pyc', '.pyo'): if os.path.isfile(os.path.join(path, '__init__' + ext)): return True vs. new syntax: for ext in ('.py', '.pyc', '.pyo') if os.path.isfile(os.path.join(path, '__init__' + ext)): return True vs. existing alternative: if any( os.path.isfile(os.path.join(path,'__init__' + ext)) for ext in ('.py','.pyc','.pyo')): return True #2 original: for dict in dicts: if name in dict: return '<a href="%s">%s</a>' % (dict[name], name) new syntax: for dict in dicts if name in dict: return '<a href="%s">%s</a>' % (dict[name], name) Cheers, David
On 12 Oct 2008, at 19:38, dbpokorny@gmail.com wrote:
What do you mean? Python's grammar is not LL(1)? Or Python + for-in-if statements is still LL(1)?
for_stmt: 'for' exprlist 'in' testlist ['if' or_test] ':' suite ['else' ':' suite]
What does that prove? If I show you: for i in L if How do you know, without looking at further tokens, whether the 'if' is part of an if-expression or part of a for-in-if statement? -- Arnaud
On Oct 12, 12:21 pm, Arnaud Delobelle <arno...@googlemail.com> wrote:
Oops! Here is what I should have said: if you replace for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] in Grammar/Grammar with the following line for_stmt: 'for' exprlist 'in' testlist_safe ['if' old_test] ':' suite ['else' ':' suite] Then the grammar is still LL(1) since it resembles the LC syntax. I neglected to turn the testlist into a testlist_safe. Now in theory this could break code...it would break anything like for x in my_list if some_condition else []: ... Now this wouldn't even be a potential problem if Python converted to a GLR parser, but that's another discussion.
You can say the same thing about an LC. The answer in that situation is the last token ('if') maps to the first element of the right-hand side of the list_if production. David
On Oct 10, 12:51 pm, Arnaud Delobelle <arno...@googlemail.com> wrote:
Not really. for_stmt: 'for' exprlist 'in' testlist ['if' or_test] ':' suite ['else' ':' suite] FWIW, I think this would be an entirely different discussion if someone did all of the work first (code+docs+test code), and THEN went to python-dev along with two or three examples from the standard library where the new syntax would *add* clarity. Side note: not to discourage anyone, but I happened to look at Lib/ pydoc.py and found several examples where, due to line-length, forcing the new syntax at every available opportunity would either substantially reduce clarity or be more or less pointless. Here are a couple cases so you can make up you own mind. #1 original: for ext in ('.py', '.pyc', '.pyo'): if os.path.isfile(os.path.join(path, '__init__' + ext)): return True vs. new syntax: for ext in ('.py', '.pyc', '.pyo') if os.path.isfile(os.path.join(path, '__init__' + ext)): return True vs. existing alternative: if any( os.path.isfile(os.path.join(path,'__init__' + ext)) for ext in ('.py','.pyc','.pyo')): return True #2 original: for dict in dicts: if name in dict: return '<a href="%s">%s</a>' % (dict[name], name) new syntax: for dict in dicts if name in dict: return '<a href="%s">%s</a>' % (dict[name], name) Cheers, David
On 12 Oct 2008, at 19:38, dbpokorny@gmail.com wrote:
What do you mean? Python's grammar is not LL(1)? Or Python + for-in-if statements is still LL(1)?
for_stmt: 'for' exprlist 'in' testlist ['if' or_test] ':' suite ['else' ':' suite]
What does that prove? If I show you: for i in L if How do you know, without looking at further tokens, whether the 'if' is part of an if-expression or part of a for-in-if statement? -- Arnaud
On Oct 12, 12:21 pm, Arnaud Delobelle <arno...@googlemail.com> wrote:
Oops! Here is what I should have said: if you replace for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] in Grammar/Grammar with the following line for_stmt: 'for' exprlist 'in' testlist_safe ['if' old_test] ':' suite ['else' ':' suite] Then the grammar is still LL(1) since it resembles the LC syntax. I neglected to turn the testlist into a testlist_safe. Now in theory this could break code...it would break anything like for x in my_list if some_condition else []: ... Now this wouldn't even be a potential problem if Python converted to a GLR parser, but that's another discussion.
You can say the same thing about an LC. The answer in that situation is the last token ('if') maps to the first element of the right-hand side of the list_if production. David
participants (3)
-
Arnaud Delobelle -
dbpokorny＠gmail.com -
Vitor Bosshard