Brian Quinlan added the comment:
Hey Ethan, I'm really sorry about dropping the ball on this. I've been burnt
out on Python stuff for the last couple of years.
When we left this, it looked like the -1s were in the majority and no one new
has jumped on to support `filter`.
If you wanted to
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: -ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
___
___
Python-bugs-list
Ethan Furman added the comment:
Brian, given my comments in msg245016 are you willing to add the
Executor.filter() function?
--
versions: +Python 3.6 -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Ethan Furman added the comment:
The recipe creates a list before it ever starts processing, while
Executor.filter() starts processing with the first item.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Ram Rachum added the comment:
Right, so it might be garbage-collecting the items before the futures are done
being created, so the whole list wouldn't need to be saved in memory. I
understand now.
--
___
Python tracker rep...@bugs.python.org
Brian Quinlan added the comment:
Actually it immediately converts the iterable into a list. Recall:
def filter(self, fn, iterable, timeout=None):
l = list(iterable) # iterable = list
return (item for (item, keep) in zip(l, self.map(fn, l, timeout)) if keep)
--
Ram Rachum added the comment:
A problem I just realized with Brian's 2-line implementation of `filter`: It
doesn't work for iterables which aren't sequences, since it attempts to exhaust
the iterable twice. So if you have a non-sequence you'll have to make it into a
sequence first.
Ram Rachum added the comment:
Raymond: Thank you. So the discussion is back on adding a recipe to the docs.
Brian: When I said possible issues, I followed that with a couple of issues
with the example I uploaded (filter_example.py).
--
___
Python
Ethan Furman added the comment:
It looks like we are pretty much neutral between the +1's and -1's.
Antoine seems to be opposed on general principles against bloat, while I am for
it on general principles of completeness.
The recipe could still go in the docs for people to use on previous
Raymond Hettinger added the comment:
I would like to tip the balance in favor of the -1. Antoine is right about
this one.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Brian Quinlan added the comment:
Ethan: I'm -0 so I'd happily go with the consensus. Does anyone have a strong
opinion?
Ram: What did you mean by Possible issues? Did you mean that to be an example
using the executor.map() technique?
--
___
Python
Nick Coghlan added the comment:
I vary between +0 and -0 for the addition of the concrete method.
When I'm at +0, the main rationale is that we *don't* have the Where do we
stop? risk here that itertools faces, as we're just replicating the
synchronous builtins.
When I'm at -0, the main
Ethan Furman added the comment:
I'd rather see an `Executor.filter()` myself, but it's Brian Quinlan's call.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
___
Ram Rachum added the comment:
Looks like this a recipe in the docs is where this ticket is headed.
I took my original example for `Executor.filter` and changed it using Brian's
suggestion so now it uses `Executor.map`. Please check it out. If someone other
than me feels comfortable in putting
Paul Moore added the comment:
I'm not a heavy user of concurrent.futures, so I don't have a strong opinion.
I've never felt a need for this function, though, so I guess I'm -0. A recipe
in the docs would be good, though.
--
___
Python tracker
Nick Coghlan added the comment:
I'm now +1 on a recipe in the docs, -0 on a concrete method on Executor
that delegates to the map() method.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Ram Rachum added the comment:
Okay, let me understand what the opinions of people are about this feature.
Ram Rachum: +1
Antoine Pitrou: -1
Nick Coghlan: Is that a +1 or a +0?
Ethan and Paul, you've participated but I didn't get your opinion on whether
you want to see this feature go in.
If
Nick Coghlan added the comment:
filter() usage has always been less common than map() usage, and we see a
similar pattern in comprehension usage as well (i.e. [f(x) for x in y] is a far
more common construct than [x for x in p(y)]). That less common status
doesn't keep us from providing
Nick Coghlan added the comment:
Folks could probably guess what I meant, but both filter comprehensions in my
comment should have read: [x for x in seq if p(x)]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Paul Moore added the comment:
Just as a note - to test a pure Pthon patch like this, you can apply the patch
to your installed Python 3.4 installation, and just run the test using that.
There should be no need to build your own Python.
python
Ram Rachum added the comment:
Patch with documentation attached. (I don't know how to concatenate patches, so
2.patch contains only the documentation, while 1.patch has the implementation
and the tests (but Ethan's patch is better.))
Brian, regarding your simpler implementation based on
Antoine Pitrou added the comment:
This feature looks unnecessary to me as well. Adding features has a non-zero
cost in maintenance.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Ethan Furman added the comment:
Short History:
=
(Ram Rachum)
What do you think about adding a method: `Executor.filter`?
I was using something like this:
my_things = [thing for thing in things if some_condition(thing)]
But the problem was that `some_condition` took a long
Ethan Furman added the comment:
That comment was from an email by Nick, not to Nick. But now I've added him.
;)
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
___
Antoine Pitrou added the comment:
(Nick Coughlan)
Nick Coghlan isn't currently on this issue. Unless you were talking about
another, separate Nick Coughlan that I don't know of? :)
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
But to answer your argument:
I think this is sufficiently tricky to get right that it's worth
adding filter() as a parallel to the existing map() API.
Tricky to get right is not a good criterion. The question is whether it's
useful or not. Only the OP has
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +bquinlan, jnoller, sbt
title: Add `Executor.filter` - Add `Executor.filter` to concurrent.futures
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24195
Brian Quinlan added the comment:
This feature seems unnecessary to me but couldn't the implementation be
simplified to work in terms of map? i.e. (pseudocode):
def filter(self, fn, iterable, timeout=None):
l = list(iterable)
return (item for (item, keep) in zip(l, self.map(fn, l, timeout))
29 matches
Mail list logo
