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.pyt...@pearwood.info> wrote:
Chris Angelico wrote:
On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
<steve+comp.lang.pyt...@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
--
https://mail.python.org/mailman/listinfo/python-list
