Guido sees the light: PEP 8 updated

[BartC]

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