On 17/04/2016 12:14, Chris Angelico wrote:
On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa <ma...@pacujo.net> wrote:
In fact, if you find yourself introducing coding "paragraphs" with
comments:
def f(...):
# I'll start by doing this
...
# segueing into the middle portion
...
# and finish it off as follows
...
you had better break those paragraphs off into separate functions. Just
turn your comments into function names.
It's really easy to do this in toy examples, isn't it? But the real
world is not so wonderful, as Alice's nanny said. What more often
happens is that, once the function exceeds the stipulated maximum, it
gets split somewhat arbitrarily into a "master" function and several
"part" functions, with each part having exactly one call site in the
driver and exactly none elsewhere. Even if the partial functions have
reasonable names (which they don't always), they're still tightly
bound to the master, and end up still functioning as a single unit.
Unless you can genuinely make that subfunction useful in some other
context, there's not a lot of use splitting it into a function. You
don't generally see those perfect "paragraphs" in real-world code.
With the additional problems that the sub-functions need a way of
accessing the local and declared names of the 'master' function. That
means creating an interface (possibly a custom one for each
sub-function) so that the master's local variables can be shared.
Except that a sub-function can't directly write to the local variables
that would be simply shared in the original monolithic function.
Besides, for a set of sub-functions that are only used by a master
function F, they really belong as local functions in F. That makes it
even bigger and more complex, although access to F's locals is simplified.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list