Python paradigms

[Malcolm Valentine]

m.faassen at vet.uu.nl aka Martijn Faassen posted:

>Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
>> Sometimes they do; sometimes they
>> don't.  I have seen codes where the median size of functions was
>> below 5 lines, and you had to keep the specification of over 50 in
>> your head just to read the simplest function!
>
>Didn't the functions have readable names then? Of course it's silly
>to take all this to ridiculous extremes, but if the naming was
>done well you have a lot of contextual information when you're reading
>a function which you wouldn't have otherwise.

  I think the murkiness is introduced when one has to remember what
exactly each of the smaller functions returns, and what each of them
does in the way of handling erroneos input,etc.

>> If you remember, I asked whether there were any equivalent to a
>> couple of very common paradigms, that have been used to clarify
>> code for over 30 years.
>
>Obfuscate code at least as often as clarify.

  The ?: operator is quite neat and easily parsed by a human reader
when it is one a single line, or two. When someone uses them in a 
huge multi-line construct filled with ->*||&&"'\ you know there is a
publican and an optomotrist in their family.

<snipped>
>in your first post, but I disagree that your ?: construction makes the
>code more easy to read than than various alternatives. I can grok C's
>(?:), but its main advantage is that it makes code more writeable, not
>more readable, in my opinion. Likewise any replacement to enable the

I'd say it ranks the same as the following;

    a,b,c,e,f,g = tupple_ware

  Note, I'm not knocking the above, but it isn't as simple as it looks.

<snipped>
>In general, the pattern in Python is that it avoids several handy but
>easy to convolute constructs; for instance we have no C style 
>for(;;) loop either, while it's clearly the general case. Instead in
                        1: Is not really any different.
                        
>No 'heretical'. Just trade-offs. Python's idioms for writing Python. The
>strategy does have a pay-off: Python code tends to be fairly readable.

  The great advantage I think is that despites ones particular methods
of coding practise, everyone can read everyone else's Python with a lot
more ease then is common in a language like C.

Cheers,
  Malcolm Valentine.