[Python-ideas] explicitation lines in python ?

[Chris Rebert]

On Fri, Jun 25, 2010 at 12:08 PM, Daniel DELAY <danieldelay at gmail.com> wrote:
> 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