Guido sees the light: PEP 8 updated
BartC
bc at freeuk.com
Sun Apr 17 08:04:05 EDT 2016
On 17/04/2016 12:14, Chris Angelico wrote:
> On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa <marko at 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
More information about the Python-list
mailing list