Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41427 > unrolled thread

Re: What are some other way to rewrite this if block?

Back to article view | Back to comp.lang.python

Contents

  Re: What are some other way to rewrite this if block? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2013-03-18 15:32 +0100
    Re: What are some other way to rewrite this if block? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-18 15:07 +0000

#41427 — Re: What are some other way to rewrite this if block?

----- Original Message -----
> This simple script is about a public transport, here is the code:
> 
> def report_status(should_be_on, came_on):
>     if should_be_on < 0.0 or should_be_on > 24.0 or came_on < 0.0 or
> came_on > 24.0:
>         return 'time not in range'
>     elif should_be_on == came_on:
>         return 'on time'
>     elif should_be_on > came_on:
>         return 'early'
>     elif should_be_on < came_on:
>         return 'delayed'
>     else:
>         return 'something might be wrong'
> 
> print(report_status(123, 12.0))
> 
> I am looking forward of make the line starting with `if` short.
> 
> Any tips are welcome.
> --
> http://mail.python.org/mailman/listinfo/python-list

You can remove the 'if' line, report_status asks for hours, the caller is supposed to provide valid hours. What if the caller gives you strings, integer, floats ?  This is a never ending story.


def report_status(should_be_on, came_on):

    # well if you really really want to test it
    assert(all([int(arg) in range(0,24) for arg in (should_be_on, came_on)])) 

    return { 0 : 'on time', -1 : 'delayed', 1 : 'early'}[cmp(should_be_on, came_on)]


JM

Note : in my example, 24.0 is excluded from the valid durations but I think this is the correct behavior.


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[toc] | [next] | [standalone]

#41432

On Mon, 18 Mar 2013 15:32:03 +0100, Jean-Michel Pichavant wrote:

> You can remove the 'if' line, report_status asks for hours, the caller
> is supposed to provide valid hours. What if the caller gives you
> strings, integer, floats ?  This is a never ending story.

I see you haven't been a programmer very long *wink*

Yes, error checking and data validation is a never ending story. Welcome 
to programming. That's what we do.



> def report_status(should_be_on, came_on):
> 
>     # well if you really really want to test it 
>     assert(all([int(arg) in range(0,24) for arg in
>       (should_be_on, came_on)]))

Please don't use assert for argument checking in public APIs. (And 
probably not in private APIs either.) assert is wrong for two reasons:

1) Invalid arguments should raise TypeError or ValueError. You wouldn't 
arbitrarily raise KeyError("expected 0 < arg < 24 but got arg = -1") or 
IOError("expected an int but got a string"). That would be unprofessional 
and foolish. So why raise AssertionError?

2) assert is not guaranteed to run, and you have *no control over it*. If 
the user calls python with the -O flag, asserts are disabled and your 
error checking is never performed.


assert is designed to verify internal logic of your code, not caller-
facing argument validation.



-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web