5 ms·

The first one is horrible and super un-pythonic (it even violates PEP8[1]). But perhaps even more important, it doesn't even work since a map-function can only

The first one is horrible and super un-pythonic (it even violates PEP8[1]). But perhaps even more important, it doesn't even work since a map-function can only take one argument (not two). Using functional programming paradigms like this often advised against in Python. [1] https://www.python.org/dev/peps/pep-0008/#programming-recommendations https://www.python.org/dev/peps/pep-0008/#programming-recomm... (search for "Always use a def statement")

gravypod 9y ago
> The first one is horrible and super un-pythonic (it even violates PEP8[1]). I'm not really concerned with PEP. I'm concerned with if the idea being expressed is cleaner then the original. My first iteration was cleaner then the original comprehension (despite the comprehension being PEP8). It also let me see what I was really doing and I was able to turn my map and filter into a much nicer list comprehension. Also, pointing out lambdas instead of defs is silly. It was done for an example. Most of the time you'll be operating on data structures with built in functions or supporting functions you will have written making it cleaner to use the map and filter paradigms. money = sum(user.get_payed_balance() for user in users if user.has_paid_bills() and user.is_still_subscribed()) bs clients = sum(map(User.get_payed_balance, filter(User.is_still_subscribed, filter(User.has_paied_bills, users)))) I much prefer the filters to the list comprehension in this case. I'll think "User's money for user in users if user has paid their bill and subscribed". I'm going to think "Sum the get_payed_balance for every user who is_still_subscribed and who has_paid_bills" for the functional implementation. If I had complex tuple arraignments then (like the OP's post) then I agree LCs will be the better way forward. If you're dealing with objects or functional-fitting problems I prefer map and filter. > But perhaps even more important, it doesn't even work since a map-function can only take one argument (not two). The concept still stands. Just use `from itertools import starmap`. Starmap is like map that calls the * operator on arguments. >>> a = lambda a, b: 10 >>> list(map(a, ((1, 2), (3, 4)))) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: <lambda>() missing 1 required positional argument: 'b' >>> list(starmap(a, ((1, 2), (3, 4)))) [10, 10] > Using functional programming paradigms like this often advised against in Python. I'm not concerned with if it's "Advised against". I'm concerned with a) will someone be able to understand this better then the implementation that currently exists) and b) will I be able to come back in 10 years and tell what this is doing if need be. You should check out this talk [1] before going around trying to use PEP8's inconsequential clauses to call something "horrible" code. [1] - https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M

gravypod 9y ago

> The first one is horrible and super un-pythonic (it even violates PEP8[1]). I'm not really concerned with PEP. I'm concerned with if the idea being expressed is cleaner then the original. My first iteration was cleaner then the original comprehension (despite the comprehension being PEP8). It also let me see what I was really doing and I was able to turn my map and filter into a much nicer list comprehension. Also, pointing out lambdas instead of defs is silly. It was done for an example. Most of the time you'll be operating on data structures with built in functions or supporting functions you will have written making it cleaner to use the map and filter paradigms. money = sum(user.get_payed_balance() for user in users if user.has_paid_bills() and user.is_still_subscribed()) bs clients = sum(map(User.get_payed_balance, filter(User.is_still_subscribed, filter(User.has_paied_bills, users)))) I much prefer the filters to the list comprehension in this case. I'll think "User's money for user in users if user has paid their bill and subscribed". I'm going to think "Sum the get_payed_balance for every user who is_still_subscribed and who has_paid_bills" for the functional implementation. If I had complex tuple arraignments then (like the OP's post) then I agree LCs will be the better way forward. If you're dealing with objects or functional-fitting problems I prefer map and filter. > But perhaps even more important, it doesn't even work since a map-function can only take one argument (not two). The concept still stands. Just use `from itertools import starmap`. Starmap is like map that calls the * operator on arguments. >>> a = lambda a, b: 10 >>> list(map(a, ((1, 2), (3, 4)))) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: <lambda>() missing 1 required positional argument: 'b' >>> list(starmap(a, ((1, 2), (3, 4)))) [10, 10] > Using functional programming paradigms like this often advised against in Python. I'm not concerned with if it's "Advised against". I'm concerned with a) will someone be able to understand this better then the implementation that currently exists) and b) will I be able to come back in 10 years and tell what this is doing if need be. You should check out this talk [1] before going around trying to use PEP8's inconsequential clauses to call something "horrible" code. [1] - https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M