On Fri, Jun 25, 2010 at 12:08 PM, Daniel DELAY
If we could explicitate
That's not a word. \> a too complex expression in an indented next line,
I would use this feature very often :
htmltable = ''.join( '<tr>{}</tr>'.format(htmlline) for line in table) : # main line htmlline : ''.join( '<td>{}</td>'.format(cell) for cell in line) # explicitation(s) line(s)
Again, not a word, and not a great name for this either, IMO.
in details :
List comprehension "<expression> for x in mylist" often greatly improve readability of python programs, when <expression> is not too complex When <expression> is too complex (ex: nested lists), this become not readable, so we have to find another solution : a) defining a function expression(x), or an iterator function, wich will only used once in the code b) or droping this beautiful syntax to replace it the very basic list construction : newlist = [] for x in myiterable newlist.append(<expression>)
I often choose b), but I dislike both solutions : - in solution a) function def can be far from list comprehension, in fact instructions to build the new list are split in two different places in the code.
What do you mean, you can put them right next to each other, and even better, give the expression a meaningful name: def line2html(line): return ''.join( '<td>{}</td>'.format(cell) for cell in line) htmltable = ''.join( '<tr>{}</tr>'.format(line2html(line)) for line in table)
- solution b) seems a bit better to me,
I'm gonna disagree with you there, but it is a somewhat subjective stylistic issue.
but the fact we build a new list from myiterable is not visible in a glance, unlike list comprehensions.
Renouncing to list comprehension occurs rather often when I write python code
I think we could greatly improve readability if we could keep list comprehension anywhere in all cases, but when necessary explicit a too complex expression in an indented line :
htmltable = ''.join( '<tr>{}</tr>'.format(htmlline) for line in table) : # main line htmlline : ''.join( '<td>{}</td>'.format(cell) for cell in line) # explicitation(s) line(s)
In the case the main line is the header of a "classical" indented block (starting with "for", "if", "with"...) , this idented block would simply follow the explicitation(s) line(s). The explicitations lines can be surely identified as the lines than begin with "identifier :" (when we are not in an unclosed dict)
with open('data.txt') as f : if line in enumerate(mylist) : # main line mylist : f.read().strip().lower() # explicitation(s) line(s) print line # "classical" indented block
Another possible use of "explicitations lines" is a coding style wich would start by "the whole picture" first, and completing with details after, wich is the usual way we mentally solve problems.
In other words, "where" clauses, à la Haskell (see http://www.haskell.org/tutorial/patterns.html section 4.5); just tweak the syntax from expr_involving_bar : bar : expr to expr_involving_bar where: bar = expr which avoids overloading colons further (i.e. constipation ;-P) and the equals sign makes more sense anyway. Having used Haskell a little bit, I can say "where" clauses can indeed make some code easier to read. However, adding them to an imperative language like Python is more problematic, since order of evaluation matters and it complicates the flow of control by causing it to go backward in "where" clauses. Basically, I don't see the problem with solution "(a)"; your general idea isn't without merit though. Cheers, Chris -- http://blog.rebertia.com