Hi, I was wondering if the builtins functions all() & any() could ever accept a custom predicate: all(iterable, predicate=bool) any(iterable, predicate=bool) Something like Lodash.js functions: every(), ... ## Example 1 ages = [21, 13, 18] major = 18..__le__ allowed = all(ages, major) ## Example 2 people = [ {"name": "Mike", "age": 42}, {"name": "Josh", "age": 17} ] major = 18..__le__ allowed = all(people, {"age": major}) ## Consistency drawbacks The filter() function takes its arguments in the reverse order: filter(predicate_or_none, iterable) I would have write this function like this... filter(iterable, predicate=None) ... but this is not the case, anyway. ## Your opinion? What do you think about this? Good idea, could be a quick-win? Or requiring a lot of efforts for nothing? What about consistency drawbacks? Thanks for reading, Titouan de Kerautem
On 3/26/2016 12:33 PM, Clint Hepner wrote:
On 2016 Mar 26 , at 12:30 p, titouan dk <dk.titouan@gmail.com> wrote:
I agree. In 3.x, which is nearly always the subject of this list, map == (2.7) itertools.imap. So proposed all(iterable, predicate) == all(map(predicate, iterable)) -- Terry Jan Reedy
On 26.03.2016 18:04, Terry Reedy wrote:
So proposed all(iterable, predicate) == all(map(predicate, iterable))
I am no native English speaker. Is predicate the right word for this? Two observations: 1) I recently saw a similar request to another "aggregate" function. 2) I can comprehend why all(map(predicate, iterable)) is harder to write. However, somehow I feel all(iterable, predicate) is harder to maintain. Because of 2) I am -1 on this. :) One could further argue that we need a another "predicate" for filtering: all(iterable, map, filter) etc. I get the feeling we would rebuilding things over and over again: list comprehensions, filter, map, itertools, for-loops etc. What about "sum", "max" etc? They all could need map + filter. Additional thought: I think the underlying issue is the number of parentheses involved. I myself somehow avoid nesting too many function calls into one line just because of that; not because of the complexity involved but because it looks strange. Of course the number of parentheses involved is an indicator of the complexity. Not sure if there is another way of handling this; maybe piping or something. Would be great if we could avoid writing ))) or ))))). Best, Sven
On Tue, Mar 29, 2016 at 9:15 AM Sven R. Kunze <srkunze@mail.de> wrote:
I'm not sure being a native speaker would help in this case. :-) One reasonably common definition of "predicate": a function that tests a condition on a value and returns True/False. Some folks define it more broadly, but then the word loses its usefulness as distinct from other kinds of functions. The usage of "predicate" here comes from predicate logic, or more specifically the usage of the term in languages like Lisp. Where Python says ``'42'.isnumeric()`` a lisper might say ``(numberp 42)``, the "p" suffix indicating that it's a predicate function. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html
I get the feeling we would rebuilding things over and over again: list comprehensions, filter, map, itertools, for-loops etc.
Certainly feels like it.
Same here. But I don't mind the occasional throwaway variable. When it's a multi-step process, a good name for an intermediate stage helps me think.
On Mar 29, 2016 12:49 PM, "Michael Selik" <mike@selik.org> wrote:
condition on a value and returns True/False. Some folks define it more broadly, but then the word loses its usefulness as distinct from other kinds of functions. The usage of "predicate" here comes from predicate logic, or more specifically the usage of the term in languages like Lisp. Where Python says ``'42'.isnumeric()`` a lisper might say ``(numberp 42)``, the "p" suffix indicating that it's a predicate function.
* "predicate" seems to be the common term * (predicate, iterable) seems to be the, at least in Python, common function signature * itertools.ifilter (predicate, iterable) https://docs.python.org/2/library/itertools.html#itertools.ifilter * python3: filter(function, iterable)) https://docs.python.org/3/library/functions.html#filter * toolz: *(predicate, iterable) * funcy.ifilter(pred, seq) http://funcy.readthedocs.org/en/stable/seqs.html#transform-and-filter ... "iterable" / sequence
a multi-step process, a good name for an intermediate stage helps me think. much easier to debug with e.g. ipdb, pdb, when there are intermediate variables. IDK if there are any less references to track without intermediate variables?
* git commit * :PymodeLintAuto #vim * git diff * git commit ... or gg=G #vim
Others have already demonstrated using generators and `map` for the general case, but FYI, the following are equivalent: 1. `all(iterable)` 2. `all(map(bool, iterable))` Because these are equivalent: 1. `if obj:` 2. `if bool(obj):` On Mar 26, 2016 12:31 PM, "titouan dk" <dk.titouan@gmail.com> wrote:
On 3/26/2016 12:33 PM, Clint Hepner wrote:
On 2016 Mar 26 , at 12:30 p, titouan dk <dk.titouan@gmail.com> wrote:
I agree. In 3.x, which is nearly always the subject of this list, map == (2.7) itertools.imap. So proposed all(iterable, predicate) == all(map(predicate, iterable)) -- Terry Jan Reedy
On 26.03.2016 18:04, Terry Reedy wrote:
So proposed all(iterable, predicate) == all(map(predicate, iterable))
I am no native English speaker. Is predicate the right word for this? Two observations: 1) I recently saw a similar request to another "aggregate" function. 2) I can comprehend why all(map(predicate, iterable)) is harder to write. However, somehow I feel all(iterable, predicate) is harder to maintain. Because of 2) I am -1 on this. :) One could further argue that we need a another "predicate" for filtering: all(iterable, map, filter) etc. I get the feeling we would rebuilding things over and over again: list comprehensions, filter, map, itertools, for-loops etc. What about "sum", "max" etc? They all could need map + filter. Additional thought: I think the underlying issue is the number of parentheses involved. I myself somehow avoid nesting too many function calls into one line just because of that; not because of the complexity involved but because it looks strange. Of course the number of parentheses involved is an indicator of the complexity. Not sure if there is another way of handling this; maybe piping or something. Would be great if we could avoid writing ))) or ))))). Best, Sven
On Tue, Mar 29, 2016 at 9:15 AM Sven R. Kunze <srkunze@mail.de> wrote:
I'm not sure being a native speaker would help in this case. :-) One reasonably common definition of "predicate": a function that tests a condition on a value and returns True/False. Some folks define it more broadly, but then the word loses its usefulness as distinct from other kinds of functions. The usage of "predicate" here comes from predicate logic, or more specifically the usage of the term in languages like Lisp. Where Python says ``'42'.isnumeric()`` a lisper might say ``(numberp 42)``, the "p" suffix indicating that it's a predicate function. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html
I get the feeling we would rebuilding things over and over again: list comprehensions, filter, map, itertools, for-loops etc.
Certainly feels like it.
Same here. But I don't mind the occasional throwaway variable. When it's a multi-step process, a good name for an intermediate stage helps me think.
On Mar 29, 2016 12:49 PM, "Michael Selik" <mike@selik.org> wrote:
condition on a value and returns True/False. Some folks define it more broadly, but then the word loses its usefulness as distinct from other kinds of functions. The usage of "predicate" here comes from predicate logic, or more specifically the usage of the term in languages like Lisp. Where Python says ``'42'.isnumeric()`` a lisper might say ``(numberp 42)``, the "p" suffix indicating that it's a predicate function.
* "predicate" seems to be the common term * (predicate, iterable) seems to be the, at least in Python, common function signature * itertools.ifilter (predicate, iterable) https://docs.python.org/2/library/itertools.html#itertools.ifilter * python3: filter(function, iterable)) https://docs.python.org/3/library/functions.html#filter * toolz: *(predicate, iterable) * funcy.ifilter(pred, seq) http://funcy.readthedocs.org/en/stable/seqs.html#transform-and-filter ... "iterable" / sequence
a multi-step process, a good name for an intermediate stage helps me think. much easier to debug with e.g. ipdb, pdb, when there are intermediate variables. IDK if there are any less references to track without intermediate variables?
* git commit * :PymodeLintAuto #vim * git diff * git commit ... or gg=G #vim
Others have already demonstrated using generators and `map` for the general case, but FYI, the following are equivalent: 1. `all(iterable)` 2. `all(map(bool, iterable))` Because these are equivalent: 1. `if obj:` 2. `if bool(obj):` On Mar 26, 2016 12:31 PM, "titouan dk" <dk.titouan@gmail.com> wrote:
participants (9)
-
Clint Hepner -
Franklin? Lee -
INADA Naoki -
Michael Selik -
Sven R. Kunze -
Terry Reedy -
titouan dk -
Victor Stinner -
Wes Turner