On 17/07/2012 19:36, Lipska the Kat wrote:
> On 17/07/12 19:18, Mark Lawrence wrote:
>> On 17/07/2012 18:29, Ethan Furman wrote:
>>> Terry Reedy wrote:
>>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>>
>>>>> Well 'type-bondage' is a strange way of thinking about compile time
>>>>> type
>>>>> checking and making code easier to read (and therefor debug
>>>>
>>>> 'type-bondage' is the requirement to restrict function inputs and
>>>> output to one declared type, where the type declaration mechanisms are
>>>> usually quite limited.
>>>>
>>>> >>> def max(a, b):
>>>> if a <= b: return a
>>>> return b
>>>
>>>
>>> Surely you meant 'if a >= b: . . .'
>>>
>>> No worries, I'm sure your unittests would have caught it. ;)
>>>
>>> ~Ethan~
>>
>> Wouldn't the compiler have caught it before the unittests? :-)
>>
> 
> Not unless the compiler could read your mind!
> The syntax looks fine it's the semantics that are suspect. Wrong is a
> word that I try not to use as it tends to upset people, let's call them
> "differently right" ;-)
> 
> BTW having more than one return statement in a block is a little thing I
> know but it drives me nuts ... another "Pythonic" thing I'll have to get
> used to I suppose.
> 

Its not a pythonic thing.  Its a common and very acceptable paradigm.

Mainly, it avoids complicated breaks from nested control structures, and
especially the 'style' of maintaining one boolean value called
"should_continue" or something equally silly.

My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
specifications and cursing violently at some of the stupidity, Python,
Bash and C++, and this is one of the few styles which remains fairly
constant throughout.

Take for example a Linux system call handler.  The general form looks a
little like (substituting C for python style pseudocode)

if not (you are permitted to do this):
    return -EPERM
if not (you've given me some valid data):
    return -EFAULT
if not (you've given me some sensible data):
    return -EINVAL
return actually_try_to_do_something_with(data)

How would you program this sort of logic with a single return statement?
 This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.

~Andrew

P.S. like the sig.
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to