List Comprehension Syntax

[Ville Vainio]

>>>>> "Eric" == Eric S Johansson <esj at harvee.org> writes:

    Eric> it all depends on your definition of natural terms.  ;-)

    Eric> For me, the abstractions I use tend to be higher level than
    Eric> what most languages support and is always a loss of clarity
    Eric> in the translation to implementation.  Python minimizes the
    Eric> translation distance for me.

That's good news, because LCs are higher level than explicit loops. 

    Eric> a particular feature.  So for example, I use for loops in
    Eric> preference to list comprehensions just because it's faster
    Eric> to implement and get the job done.

That's mostly a result of you not a comfortable grasp of LCs yet. As
with most things in Python, learning them is going to be worth the
time used for learning.


    Eric> your observation about reasons for choosing languages are
    Eric> certainly accurate for most people but for me, it's quite
    Eric> different.  If I can't write code using speech recognition
    Eric> without doing a job on my throat, I won't use the language.
    Eric> List comprehension syntax is approaching dammed ugly for
    Eric> speech recognition users.

How? The only special thing about LCs are the surrounding ['s. It's
also a lot less speaking, which is probably a good thing. 

Admittedly I have never used speech recognition software. How do you
speak out the following equivalent snippets:

----

files = [f.lower() for f in allfiles if f.endswith(".txt")]

----


files = []
for f in allfiles:
  if f.endswith(".txt"):
    files.append(f.lower())

----


If it has something to do with line breaking, the following is
obviously ok too (and in no way inferior to the one-line approach):

files = [f.lower()
         for f in allfiles 
         if f.endswith(".txt")]



-- 
Ville Vainio   http://tinyurl.com/2prnb