Temporary variables in list comprehensions
steve+comp.lang.python at pearwood.info
Sun Jan 8 23:49:10 EST 2017
On Monday 09 January 2017 15:09, Chris Angelico wrote:
> On Mon, Jan 9, 2017 at 2:53 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> [(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
>> I can't decide whether that's an awesome trick or a horrible hack...
> A horrible hack on par with abusing a recursive function's arguments
> for private variables.
What's wrong with that? That's a perfectly legitimate technique. I prefer to
hide it behind a private function rather than expose it in a public interface:
# instead of this
def recursive(arg, _internal=None):
"""Recursive function. Don't supply the _internal argument."""
return recursive(arg-1, spam)
# I usually prefer this
return _recursive(arg, spam)
def _recursive(arg, internal):
but that's just polishing the code.
> Much better would be to refactor the append
> def this_and_one(value):
> return value, value + 1
I wouldn't call that "much better". Requiring an extra function defeats the
purpose of using a list comp, and it doesn't scale well for multiple list comps
each of which needs a different helper function:
return value, value + 1
return value - 1, value + 1, value
return value, value.that() or something
return spam[value] or ham[value] or eggs[value]
and so on. Helper functions are good. Helper functions that are only used
*once* are a code smell. *LOTS* of helper functions that are only used once are
a sign that something is horrible, and it might just be your language...
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
More information about the Python-list