Testing dynamic languages

Discussion in 'Python' started by grkuntzmd@gmail.com, Apr 4, 2009.

  1. Guest

    I am a Java developer. There, I said it :).

    When I am writing code, I can rely on the compiler to confirm that
    any methods I write will be called with parameters of the "right"
    type. I do not need to test that parameter #1 really is a String
    before I call some method on it that only works on Strings.

    If I am writing in Python, since it is dynamically, but strongly
    typed, I really should check that each parameter is of the expected
    type, or at least can respond to the method I plan on calling ("duck"
    typing). Every call should be wrapped in a try/except statement to
    prevent the method (and program) from crashing when my method is
    called with an integer instead of the expected string.

    Is this the experience that Python programmer (of large projects) see?
    Do you also write unit tests to confirm that the methods actually
    check for and catch "bad" parameter types? If I am writing small one-
    off scripts, I wouldn't worry about it, but if I am writing a large
    system that must have 99+% uptime without constant monitoring, this
    really should be verified.

    Up for discussion...
     
    , Apr 4, 2009
    #1
    1. Advertising

  2. On Saturday 04 April 2009 15:37:44 wrote:
    > I am a Java developer. There, I said it :).
    >
    > When I am writing code, I can rely on the compiler to confirm that
    > any methods I write will be called with parameters of the "right"
    > type. I do not need to test that parameter #1 really is a String
    > before I call some method on it that only works on Strings.
    >
    > If I am writing in Python, since it is dynamically, but strongly
    > typed, I really should check that each parameter is of the expected
    > type, or at least can respond to the method I plan on calling ("duck"
    > typing). Every call should be wrapped in a try/except statement to
    > prevent the method (and program) from crashing when my method is
    > called with an integer instead of the expected string.


    Well, it depends on what you're trying to do, really. You do *not* want to
    check parameters in every function. If you are designing a library, it is
    strongly advised to document what kind of parameters your functions
    expect. Otherwise, if your program will handle arbitrary input, you should
    check its format and reject it if it's invalid.

    Cheers,

    Emm
     
    Emmanuel Surleau, Apr 4, 2009
    #2
    1. Advertising

  3. On Apr 4, 11:17 am, Emmanuel Surleau <>
    wrote:
    > On Saturday 04 April 2009 15:37:44 wrote:
    >
    > > I am a Java developer. There, I said it :).


    Don't worry. I also do terrible things to support my family...
     
    Luis Gonzalez, Apr 4, 2009
    #3
  4. Tim Wintle Guest

    On Sat, 2009-04-04 at 06:37 -0700, wrote:
    > If I am writing in Python, since it is dynamically, but strongly
    > typed, I really should check that each parameter is of the expected
    > type, or at least can respond to the method I plan on calling ("duck"
    > typing). Every call should be wrapped in a try/except statement to
    > prevent the method (and program) from crashing when my method is
    > called with an integer instead of the expected string.


    At some point you should wrap it in a try/except block - but only at the
    point where you want the exception to be handled. That will normally be
    quite far up, and you'll just let the exception travel back up to that
    point.


    for example, in a web server type of thing you might have something
    vaguely like


    def main:
    for request in request_itter:
    try:
    headers = request.get_headers()
    dispatch = get_dispatch_fn(headers)
    response = dispatch(response)
    except:
    send_500()

    You probably then don't need to catch any exceptions in the get_headers,
    or actual processing methods (unless you are writing to sql or
    something, when you might want to wrap all statements in a try block,
    and then put a "ROLLBACK;" query in the except block (and then raise the
    caught exception so it goes back the the block above)

    >
    > Is this the experience that Python programmer (of large projects) see?
    > Do you also write unit tests to confirm that the methods actually
    > check for and catch "bad" parameter types? If I am writing small one-
    > off scripts, I wouldn't worry about it, but if I am writing a large
    > system that must have 99+% uptime without constant monitoring, this
    > really should be verified.


    I write large applications with a target of 99.9% uptime, and I don't
    find it a problem. occasionally I have to check parameters, but that's
    not very often

    >
    > Up for discussion...
    > --
    > http://mail.python.org/mailman/listinfo/python-list
     
    Tim Wintle, Apr 4, 2009
    #4
  5. Guest

    This may be obvious but, clearly there are (at least) two general
    types of errors: those caused by data external to the program and
    those caused by bugs in the program. For all inputs coming into the
    program from outside, such as user inputs and data coming over a
    network, the inputs must be completely checked -- always assume that
    they will be incorrect and are intended to crash your code -- be
    pleasantly surprised when they are not :). Check for all bad inputs.

    If the data are from inside the program, the assumption may be that
    they are good and if not, it was a bug. I suppose you can write unit
    tests on each routine to see that the methods that routine calls are
    with valid arguments (using mocks). I actually tried this in a Java
    program using JMockit; it was tedious, but it did catch a few
    "potential" bugs. I would love to say that I ALWAYS remember the input
    and output condition of every subroutine I write, but I just finished
    a new feature for a company project that involved 100+ routines and
    classes and I admit that I don't always remember which ones can return
    null and which always return empty arrays, for example, even though I
    try to write JavaDocs at the top of each routine. By mocking these
    routines, I can check that the caller always handles each case
    gracefully.
     
    , Apr 4, 2009
    #5
  6. Guest

    grkunt...:
    > If I am writing in Python, since it is dynamically, but strongly
    > typed, I really should check that each parameter is of the expected
    > type, or at least can respond to the method I plan on calling ("duck"
    > typing). Every call should be wrapped in a try/except statement to
    > prevent the method (and program) from crashing when my method is
    > called with an integer instead of the expected string.


    Others have already given you most of the answers (summary: don't do
    that. Don't fight the language. Use doctests). My other suggestion is
    to read code coming from 5+ Python programs written by other
    (different) people. You will see how to use Python.

    Bye,
    bearophile
     
    , Apr 4, 2009
    #6
  7. barisa Guest

    On Apr 4, 9:57 pm, wrote:

    > that. Don't fight the language. Use doctests). My other suggestion is
    > to read code coming from 5+ Python programs written by other
    > (different) people. You will see how to use Python.
    >
    > Bye,
    > bearophile


    Is there some online repository for such code?
    :)

    Regards
    Begginer
     
    barisa, Apr 5, 2009
    #7
  8. Plenty. Try github.com for starters.

    -----Original Message-----
    From: python-list-bounces+nick=
    [mailto:python-list-bounces+nick=] On Behalf Of
    barisa
    Sent: Sunday, April 05, 2009 10:22 AM
    To:
    Subject: Re: Testing dynamic languages

    On Apr 4, 9:57 pm, wrote:

    > that. Don't fight the language. Use doctests). My other suggestion is
    > to read code coming from 5+ Python programs written by other
    > (different) people. You will see how to use Python.
    >
    > Bye,
    > bearophile


    Is there some online repository for such code?
    :)

    Regards
    Begginer
    --
    http://mail.python.org/mailman/listinfo/python-list
     
    Nick Stinemates, Apr 5, 2009
    #8
  9. Aahz Guest

    In article <>,
    barisa <> wrote:
    >On Apr 4, 9:57=A0pm, wrote:
    >
    >> that. Don't fight the language. Use doctests). My other suggestion is
    >> to read code coming from 5+ Python programs written by other
    >> (different) people. You will see how to use Python.
    >> bearophile

    >
    >Is there some online repository for such code?


    Start with Lib/ in the source ;-)
    --
    Aahz () <*> http://www.pythoncraft.com/

    "...string iteration isn't about treating strings as sequences of strings,
    it's about treating strings as sequences of characters. The fact that
    characters are also strings is the reason we have problems, but characters
    are strings for other good reasons." --Aahz
     
    Aahz, Apr 5, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roel Wuyts
    Replies:
    0
    Views:
    330
    Roel Wuyts
    Jul 6, 2004
  2. Neuruss

    Dynamic languages

    Neuruss, Aug 27, 2004, in forum: Python
    Replies:
    11
    Views:
    842
    Peter Hansen
    Aug 31, 2004
  3. Paul Boddie

    Papers on Dynamic Languages

    Paul Boddie, Mar 4, 2006, in forum: Python
    Replies:
    1
    Views:
    325
    Jay Parlar
    Mar 4, 2006
  4. Marvin
    Replies:
    3
    Views:
    411
    bruno at modulix
    Jun 2, 2006
  5. James Britt
    Replies:
    2
    Views:
    127
    Jacek
    Dec 10, 2004
Loading...

Share This Page