Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: List Comprehensions
Date: Mon, 22 Dec 2014 15:28:24 -0500
References: <mailman.17108.1419226965.18130.python-list@python.org> <5497e2a2$0$12978$c3e8da3$5496439d@news.astraweb.com> <mailman.17116.1419241532.18130.python-list@python.org> <5498362f$0$12994$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmoh4nb0uyhwsm_NPGovgcvekbkAuMN6rMpZqsjah_s1Pw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
In-Reply-To: <CAPTjJmoh4nb0uyhwsm_NPGovgcvekbkAuMN6rMpZqsjah_s1Pw@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.17135.1419280133.18130.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:82804

On 12/22/2014 12:10 PM, Chris Angelico wrote:
> On Tue, Dec 23, 2014 at 2:18 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Chris Angelico wrote:
>>
>>> On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
>>> <steve+comp.lang.python@pearwood.info> wrote:
>>>> If the called function has side-effects, a list comp is not a good
>>>> solution.
>>>
>>> Hmm. I'm not so sure about that. Side effects are fine in a list comp,
>>> as long as you're making use of the return values. For instance, if
>>> you have a function that inserts a record to a database and returns
>>> the new ID, you could reasonably use a list comp to save a bunch of
>>> records and get a list of IDs for subsequent use.
>>
>> I hear what you are saying, but a list comprehension is a functional idiom.

In particular, it is a way to hide the mutational, non-functional, 
.append that is a necessary part of constructing an array of references 
in contiguous memory on a physical machine.

>> To mix functional and procedural idioms in the one expression is rather
>> icky.

A list comp with side-effects in the target expression is definitely a 
subversion of the original intent.  Whether Python programmers should 
respect that intent is another matter.  Limiting the 
opinion/recommendation to single expressions makes it more defensible 
than something broader.

>> Better to use one or the other but not both simultaneously.
>> I'll accept that this is a weak recommendation though.


> In my opinion, trying to separate functional and procedural idioms is
> like trying to separate 'for' loops and recursion; they're two tools

A for loop with a recursive call in its body is not 'one expression'. 
Moreover, it is easy to claim that driving multiple recursion with a for 
loop is clearer than using the recursive equivalent of a for loop to 
drive the 'horizontal' repetition.  Untested example for preorder 
traversal of a tree where nodes have ordered children:

def preorder(node):
   yield node
   for child in node.children():  # horizontal repetition
        yield from preorder(child)  # vertically nested repetition

I do not see any such gain over Ganesh Pal's original for-loop code.

> that can be used separately or together, in whatever way makes the
> most sense. Given that side-effecting functions are a mess in
> functional programming anyway, of course they cause problems for
> functional idioms; but if it's okay to have side effects at all, it
> ought to be okay to have side effects of a list comp.

I see this as equivalent to "If it is okay to have separated side 
effects, it ought to be okay to have mixed-in side effects."

I am not claiming that I would *never* use side effects in a list comp, 
but I am sympathetic to the objection.

-- 
Terry Jan Reedy