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.pyt...@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
def recursive(arg):
"""Recursive function."""
return _recursive(arg, spam)
def _recursive(arg, internal):
...
but that's just polishing the code.
> Much better would be to refactor the append
> part:
>
> 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:
def this_and_one(value):
return value, value + 1
def this_less_one_and_this_plus_one_and_this(value):
return value - 1, value + 1, value
def this_and_that_or_something(value):
return value, value.that() or something
def extract_value(value):
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...
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
