How to detect typos in Python programs

Discussion in 'Python' started by Manish Jethani, Jul 25, 2003.

  1. Hi all,

    Is there a way to detect typos in a Python program, before
    actually having to run it. Let's say I have a function like this:

    def server_closed_connection():
    session.abost()

    Here, abort() is actually misspelt. The only time my program
    follows this path is when the server disconnects from its
    end--and that's like once in 100 sessions. So sometimes I
    release the program, people start using it, and then someone
    reports this typo after 4-5 days of the release (though it's
    trivial to fix manually at the user's end, or I can give a patch).

    How can we detect these kinds of errors at development time?
    It's not practical for me to have a test script that can make
    the program go through all (most) the possible code paths.

    -Manish

    --
    Manish Jethani (manish.j at gmx.net)
    phone (work) +91-80-51073488
     
    Manish Jethani, Jul 25, 2003
    #1
    1. Advertising

  2. Manish Jethani

    Peter Hansen Guest

    Manish Jethani wrote:
    >
    > Is there a way to detect typos in a Python program, before
    > actually having to run it. Let's say I have a function like this:
    >
    > def server_closed_connection():
    > session.abost()
    >
    > Here, abort() is actually misspelt. The only time my program
    > follows this path is when the server disconnects from its
    > end--and that's like once in 100 sessions. So sometimes I
    > release the program, people start using it, and then someone
    > reports this typo after 4-5 days of the release (though it's
    > trivial to fix manually at the user's end, or I can give a patch).
    >
    > How can we detect these kinds of errors at development time?
    > It's not practical for me to have a test script that can make
    > the program go through all (most) the possible code paths.


    You have no good alternative. Why do you say it's impractical
    to actually test your software before it's shipped? Isn't it
    more impractical to rely on your users to test the software,
    thinking it should work?

    Unit testing in Python is *really* easy. I can't think of any
    reason not to do it as the best way of catching problems like you
    show above. If you resist :), however, you might find PyChecker
    will help. I'm not sure if it can do anything in the above case
    yet, however.

    -Peter
     
    Peter Hansen, Jul 25, 2003
    #2
    1. Advertising

  3. Alexandre Fayolle, Jul 25, 2003
    #3
  4. Manish Jethani

    aj coon Guest

    Manish Jethani <> wrote in message news:<ZPaUa.6$>...
    > Hi all,
    >
    > Is there a way to detect typos in a Python program, before
    > actually having to run it. Let's say I have a function like this:
    >
    > def server_closed_connection():
    > session.abost()
    >
    > Here, abort() is actually misspelt. The only time my program
    > follows this path is when the server disconnects from its
    > end--and that's like once in 100 sessions. So sometimes I
    > release the program, people start using it, and then someone
    > reports this typo after 4-5 days of the release (though it's
    > trivial to fix manually at the user's end, or I can give a patch).
    >
    > How can we detect these kinds of errors at development time?
    > It's not practical for me to have a test script that can make
    > the program go through all (most) the possible code paths.
    >
    > -Manish



    This is one of the things about interpreted languages that I detest-
    lack of compile-time errors and warnings. With python, you can
    always open an interactive session with the interpreter and 'import
    <filename>', but that only catches syntax errors.

    For things like unreferenced variables and undefined names (typos, as
    you like to nicely put it ;-), theres a program we use for testing our
    code:

    http://pychecker.sourceforge.net/

    Have a look. Admittedly, the information it outputs can be
    overwhelming. Take some time to just examine its behaviors and
    options. What you'll probably end up doing is customizing its output,
    either by modifying the source, or running it through
    grep/awk/sed/python afterwards. But, it's definitely a starting
    point.


    -AJ
     
    aj coon, Jul 25, 2003
    #4
  5. Manish Jethani

    Richard Guest

    Manish Jethani <> wrote in message news:<ZPaUa.6$>...
    > Hi all,
    >
    > Is there a way to detect typos in a Python program, before
    > actually having to run it. Let's say I have a function like this:
    >
    > def server_closed_connection():
    > session.abost()
    >
    > Here, abort() is actually misspelt. The only time my program
    > follows this path is when the server disconnects from its
    > end--and that's like once in 100 sessions. So sometimes I
    > release the program, people start using it, and then someone
    > reports this typo after 4-5 days of the release (though it's
    > trivial to fix manually at the user's end, or I can give a patch).
    >
    > How can we detect these kinds of errors at development time?
    > It's not practical for me to have a test script that can make
    > the program go through all (most) the possible code paths.
    >
    > -Manish


    Two words! Unit Testing!

    Just do a google search on "Python unit testing" and I'm sure you'll
    get more information than you ever wanted to know.

    Richard
     
    Richard, Jul 25, 2003
    #5
  6. Manish Jethani

    Ed Phillips Guest

    Beefing up socket.ssl(...)

    From looking at Modules/socketmodule.c in 2.2.2 and 2.2.3, it appears that
    only a tiny bit of support for SSL has been added. Specifically, unless
    I'm misunderstanding the operation of the code, there's no way to verify
    the certificate presented by a server. The code necessary to cause such
    verification is pretty straightforward for simple "verify the server
    certificate" purposes so I hacked together some changes to 2.2.2
    socketmodule.c to verify the certificates (see below).

    So now, I can do something like this:

    from socket import *

    s = socket(AF_INET, SOCK_STREAM)
    a = ('www.mycompany.net', 443)
    s.connect(a)
    v = ssl(s, '', 'mycacerts.pem')

    ....and the server certificate is verified according to the CA certs stored
    in the file. I'm not sure of the intent of the
    SSL_CTX_use_PrivateKey_file() and SSL_CTX_use_certificate_chain_file()
    calls in the original socketmodule.c ... they don't seem to do much that
    is useful at the Python level AFAICT. I guess if you were going to use
    client certs, and your server requested peer authentication, then it would
    somehow use private key file (which I guess would contain the client cert
    and the client private key?) to initiate a client-auth process, but in the
    normal "I just want to verify the server I'm connecting to has the correct
    certificate" context, my version seems to be a sufficient starting point.
    I also, I don't understand the motivation behind requiring both the
    key_file and cert_file parms.

    I'm not very good with Python extension modules yet (or OpenSSL for that
    matter), so I have a printf() stuck in there just to get a meaningful
    error about the verification process. This could probably be changed to
    mimic what PySSL_SetError(..) does and return an actual error code and
    error string tuple, but that's just icing.

    Also, I noticed that at line 2736 of socketmodule.c (original 2.2.2
    version; line 2741 in the 2.2.3 version) there is a "return NULL;"
    statement missing that may need to be fixed. I don't know what to do with
    this info. other than post it to this list... maybe someone reading this
    list will run with it...?

    Do others beside me find SSL features lacking in Python? Do you use some
    other module to provide SSL features rather than the basic socket module?

    Thanks,

    Ed

    Ed Phillips <> University of Delaware (302) 831-6082
    Systems Programmer III, Network and Systems Services
    finger -l for PGP public key

    *** Modules/socketmodule.c_orig Thu Jul 24 12:26:16 2003
    --- Modules/socketmodule.c Thu Jul 24 17:08:36 2003
    ***************
    *** 2760,2769 ****
    --- 2760,2771 ----
    self->ctx = NULL;
    self->Socket = NULL;

    + /*
    if ((key_file && !cert_file) || (!key_file && cert_file)) {
    errstr = "Both the key & certificate files must be
    specified";
    goto fail;
    }
    + */

    self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
    if (self->ctx == NULL) {
    ***************
    *** 2771,2788 ****
    goto fail;
    }

    ! if (key_file) {
    if (SSL_CTX_use_PrivateKey_file(self->ctx, key_file,
    SSL_FILETYPE_PEM) < 1) {
    errstr = "SSL_CTX_use_PrivateKey_file error";
    goto fail;
    }

    if (SSL_CTX_use_certificate_chain_file(self->ctx,
    cert_file) < 1) {
    errstr = "SSL_CTX_use_certificate_chain_file
    error";
    goto fail;
    }
    }

    SSL_CTX_set_verify(self->ctx,
    --- 2773,2799 ----
    goto fail;
    }

    ! if (key_file && *key_file) {
    if (SSL_CTX_use_PrivateKey_file(self->ctx, key_file,
    SSL_FILETYPE_PEM) < 1) {
    errstr = "SSL_CTX_use_PrivateKey_file error";
    goto fail;
    }
    + }

    + if (cert_file && *cert_file) {
    + if (SSL_CTX_load_verify_locations(self->ctx, cert_file,
    NULL)
    + < 1) {
    + errstr = "SSL_CTX_load_verify_locations error";
    + goto fail;
    + }
    + /*
    if (SSL_CTX_use_certificate_chain_file(self->ctx,
    cert_file) < 1) {
    errstr = "SSL_CTX_use_certificate_chain_file
    error";
    goto fail;
    }
    + */
    }

    SSL_CTX_set_verify(self->ctx,
    ***************
    *** 2805,2810 ****
    --- 2816,2828 ----
    self->server, X509_NAME_MAXLEN);
    X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
    self->issuer, X509_NAME_MAXLEN);
    + ret = SSL_get_verify_result(self->ssl);
    + if (ret != X509_V_OK) {
    + /* errstr = "SSL_get_verify_result error"; */
    + printf("SSL_get_verify_result returned %d\n",
    ret);
    + PySSL_SetError(self->ssl, ret);
    + goto fail;
    + }
    }
    self->Socket = Sock;
    Py_INCREF(self->Socket);
     
    Ed Phillips, Jul 25, 2003
    #6
  7. Re: Beefing up socket.ssl(...)

    Ed> From looking at Modules/socketmodule.c in 2.2.2 and 2.2.3, it
    Ed> appears that only a tiny bit of support for SSL has been added.
    Ed> Specifically, unless I'm misunderstanding the operation of the code,
    Ed> there's no way to verify the certificate presented by a server.

    Note that since 2.2.3 is just a bugfix release, you shouldn't expect any
    increase in functionality. I'm mildly surprised that you noticed any
    functional changes between 2.2.2 and 2.2.3.

    I suggest you take 2.3c2 out for a spin and see if it has more of the
    features you're after. (2.3final is due out by the end of the month.) In
    any case, if you have patches to submit, please use SourceForge and note
    that any functional improvements will be targetted at 2.4 at this point.
    You can find more about patch submission at the Patch Submission Guidelines
    page:

    http://www.python.org/patches/

    Thx,

    Skip
     
    Skip Montanaro, Jul 25, 2003
    #7
  8. Mel Wilson wrote:

    > In article <>,
    > Peter Hansen <> wrote:
    >
    >>Manish Jethani wrote:
    >>
    >>>Is there a way to detect typos in a Python program, before
    >>>actually having to run it. Let's say I have a function like this:
    >>>
    >>> def server_closed_connection():
    >>> session.abost()
    >>>
    >>>Here, abort() is actually misspelt. The only time my program
    >>>follows this path is when the server disconnects from its
    >>>end--and that's like once in 100 sessions. [ ... ]

    >>
    >>You have no good alternative. Why do you say it's impractical
    >>to actually test your software before it's shipped? Isn't it
    >>more impractical to rely on your users to test the software,
    >>thinking it should work?

    >
    >
    > The proposed typo catcher would probably catch a typo like
    >
    > sys.edit (5) # finger didn't get off home row
    >
    > but it probably would *NOT* catch
    >
    > sys.exit (56) # wide finger mashed two keys


    1) That's in a different class of typos. Such things can't be
    auto-detected in any language. It will probably require close
    examination by the human who wrote it in the first place, or
    someone who has been debugging it.

    2) No on calls sys.exit() like that. 5, or 56, is probably a
    constant defined somewhere (where such typos are easier to spot).

    -Manish

    --
    Manish Jethani (manish.j at gmx.net)
    phone (work) +91-80-51073488
     
    Manish Jethani, Jul 25, 2003
    #8
  9. Manish Jethani

    Ed Phillips Guest

    Re: Beefing up socket.ssl(...)

    On Fri, 25 Jul 2003, Skip Montanaro wrote:

    > Ed> From looking at Modules/socketmodule.c in 2.2.2 and 2.2.3, it
    > Ed> appears that only a tiny bit of support for SSL has been added.
    > Ed> Specifically, unless I'm misunderstanding the operation of the code,
    > Ed> there's no way to verify the certificate presented by a server.
    >
    > Note that since 2.2.3 is just a bugfix release, you shouldn't expect any
    > increase in functionality. I'm mildly surprised that you noticed any
    > functional changes between 2.2.2 and 2.2.3.


    Sorry, I didn't mean to imply they were different... I just meant that I
    looked at them both (not realizing they should be the same except for bug
    fixes). By "only a tiny bit of support for SSL has been added", I meant
    "... to Python in general as of 2.2.2 and 2.2.3".

    > I suggest you take 2.3c2 out for a spin and see if it has more of the
    > features you're after. (2.3final is due out by the end of the month.)


    Hmmmm... well, I guess I can take a look at socketmodule.c in 2.3c2 and
    see if it's any different than previous versions as far as the amount of
    SSL functionality goes.

    > In any case, if you have patches to submit, please use SourceForge and
    > note that any functional improvements will be targetted at 2.4 at this
    > point. You can find more about patch submission at the Patch Submission
    > Guidelines page:
    >
    > http://www.python.org/patches/


    I'm not sure whether this "functional change" would be considered a "bug
    fix" or "feature addition". The SSL support in socketmodule.c seems to be
    lacking almost to the point of being "unusable"... I can't imagine anyone
    actually using it for anything "real" in it's current state, and in that
    sense, it may be legitimate to call my changes a "bug fix".

    I guess I could attack it either way. I could modify the existing
    socket.ssl() pieces to work "better" (at least in the normal "act like a
    web browser and verify server certs" sense), or I could add new
    "features". It might be nice to have a socket.sslclient() method that
    would verify the server cert and optionally authenticate with a client
    certificate (although the client auth part is probably out of my league at
    this point), along with a socket.sslserver() method which would perform
    the normal server-side SSL duties.

    Or I could just hack on socketmodule.c with every new Python release and
    hope that someone eventually adds better SSL support. Anyone working on
    that already?

    Thanks,

    Ed

    Ed Phillips <> University of Delaware (302) 831-6082
    Systems Programmer III, Network and Systems Services
    finger -l for PGP public key
     
    Ed Phillips, Jul 25, 2003
    #9
  10. Re: Beefing up socket.ssl(...)


    >> http://www.python.org/patches/


    Ed> I'm not sure whether this "functional change" would be considered a
    Ed> "bug fix" or "feature addition". The SSL support in socketmodule.c
    Ed> seems to be lacking almost to the point of being "unusable"... I
    Ed> can't imagine anyone actually using it for anything "real" in it's
    Ed> current state, and in that sense, it may be legitimate to call my
    Ed> changes a "bug fix".

    This is open source. If you don't submit the code, who will? ;-)

    Also, note that the SSL code has been factored out into Modules/_ssl.c.

    Ed> Or I could just hack on socketmodule.c with every new Python release
    Ed> and hope that someone eventually adds better SSL support.

    If nobody ever submits such code it will never get into Python. Essentially
    all functionality that's there today is because writing it scratched an itch
    for the author.

    Skip
     
    Skip Montanaro, Jul 25, 2003
    #10
  11. Quoth Manish Jethani:
    [...]
    > Actually I am writing a client app for a proprietary service.
    > The server is not under my control, so I can't make it behave in
    > a way that will cause every part of my client code to be tested.
    > As I mentioned, for example, I have a function to handle a
    > server-disconnect. But the server rarely ever disconnects of
    > its own, so the function never gets called in reality. Can I
    > unit test this function easily?


    Mock objects are the usual approach to this kind of problem.
    (Google can tell you more.)

    --
    Steven Taschuk
    Receive them ignorant; dispatch them confused. (Weschler's Teaching Motto)
     
    Steven Taschuk, Jul 25, 2003
    #11
  12. Manish Jethani

    John Roth Guest

    Make it a policy that your unit test suite has 100%
    statement coverage at all times. Then this
    particular thing won't happen.

    How do you do this without impacting your
    development? Try Test Driven Development.
    If you do it *properly*, you'll get close to
    100% statement coverage without any extra
    effort.

    John Roth

    "Manish Jethani" <> wrote in message
    news:ZPaUa.6$...
    > Hi all,
    >
    > Is there a way to detect typos in a Python program, before
    > actually having to run it. Let's say I have a function like this:
    >
    > def server_closed_connection():
    > session.abost()
    >
    > Here, abort() is actually misspelt. The only time my program
    > follows this path is when the server disconnects from its
    > end--and that's like once in 100 sessions. So sometimes I
    > release the program, people start using it, and then someone
    > reports this typo after 4-5 days of the release (though it's
    > trivial to fix manually at the user's end, or I can give a patch).
    >
    > How can we detect these kinds of errors at development time?
    > It's not practical for me to have a test script that can make
    > the program go through all (most) the possible code paths.
    >
    > -Manish
    >
    > --
    > Manish Jethani (manish.j at gmx.net)
    > phone (work) +91-80-51073488
    >
    >
     
    John Roth, Jul 26, 2003
    #12
  13. John J. Lee wrote:

    > Manish Jethani <> writes:
    > [...]
    >
    >>>The proposed typo catcher would probably catch a typo like
    >>>
    >>> sys.edit (5) # finger didn't get off home row
    >>>
    >>>but it probably would *NOT* catch
    >>>
    >>> sys.exit (56) # wide finger mashed two keys

    >>
    >>1) That's in a different class of typos. Such things can't be
    >>auto-detected in any language. It will probably require close
    >>examination by the human who wrote it in the first place, or
    >>someone who has been debugging it.

    >
    >
    > That was, indeed, precisely the point that was being made. Tests can
    > catch these, static type analysis can't.


    There's a difference between my "abost()" example and the "56"
    example. There's no function called abost anywhere in the
    program text, so I should be able to detect the error with
    static analysis. Even in C, the compiler warns about stray
    function calls.

    The "56" example is out of place here. I have fixed the code:

    --------
    [maybe a constants.py or whatever]
    arbit_code = 56

    [... elsewhere...]

    sys.exit(arbir_code)
    --------

    That error can be caught in static analysis.

    >>2) No on calls sys.exit() like that. 5, or 56, is probably a
    >>constant defined somewhere (where such typos are easier to spot).

    >
    >
    > Yes. Do you have a point?


    Yes. Don't use bad coding practices as an excuse.

    -Manish

    --
    Manish Jethani (manish.j at gmx.net)
    phone (work) +91-80-51073488
     
    Manish Jethani, Jul 27, 2003
    #13
  14. Manish Jethani

    Peter Hansen Guest

    Manish Jethani wrote:
    >
    > There's a difference between my "abost()" example and the "56"
    > example. There's no function called abost anywhere in the
    > program text, so I should be able to detect the error with
    > static analysis. Even in C, the compiler warns about stray
    > function calls.


    You don't understand the dynamic nature of Python if you
    think this is something that is either easy or 100% reliable.

    Very contrived but instructive example:

    def func(x):
    pass

    import sys
    setattr(sys, 'ab' + 'ost', func)

    stick-that-in-your-static-analyzer-and-smoke-it-ly y'rs
    -Peter
     
    Peter Hansen, Jul 29, 2003
    #14
  15. Manish Jethani

    Ganesan R Guest

    >>>>> "Peter" == Peter Hansen <> writes:

    > You don't understand the dynamic nature of Python if you
    > think this is something that is either easy or 100% reliable.


    > Very contrived but instructive example:


    > def func(x):
    > pass


    > import sys
    > setattr(sys, 'ab' + 'ost', func)


    > stick-that-in-your-static-analyzer-and-smoke-it-ly y'rs


    The dynamic nature of Python is definitely a problem but there are some
    obvious workarounds. For example a static analyzer can take an option that
    says "assume standard modules are not modified". This is probably good
    enough for 90% of the cases.

    Ganesan

    --
    Ganesan R
     
    Ganesan R, Jul 29, 2003
    #15
  16. Manish Jethani

    David Bolen Guest

    Manish Jethani <> writes:

    > There's a difference between my "abost()" example and the "56"
    > example. There's no function called abost anywhere in the
    > program text, so I should be able to detect the error with
    > static analysis. Even in C, the compiler warns about stray
    > function calls.


    But in your example, you were calling "session.abost". Due to
    Python's dynamic nature, there's no way for a static compile-time
    analysis to know for sure if the object to which session (I'm guessing
    it's a global from the code) refers _at the point when that code
    executes_ has an abost method or not. Or rather, no way I can see
    other than having the compiler actually execute the code to determine
    that fact.

    Given that you want some specific behavior to occur on a close
    connection event, you're really best served by having a test that
    actually simulates such an event to verify that your action occurs.
    That's true in any language, although particularly so in Python. It's
    certainly best to use automated tests, but even some manual setup for
    more complicated network situations can help. For example, if I were
    writing such a system, I'd probably at least manually start up a
    modified server that explicitly disconnected more frequently so I
    could exercise that aspect of tear-down more easily. Otherwise
    (syntax checks or no), I'd be releasing code without really having any
    idea that it would do the right thing in such a teardown situation.

    Think of it just as another aspect to "good coding practices".

    -- David
     
    David Bolen, Jul 29, 2003
    #16
    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. dagoodyear

    Parsing text acounting for typos?

    dagoodyear, Jun 12, 2005, in forum: Java
    Replies:
    1
    Views:
    392
    Harald
    Jun 12, 2005
  2. Siemel Naran

    typos in set functions

    Siemel Naran, Nov 30, 2004, in forum: C++
    Replies:
    5
    Views:
    383
    Siemel Naran
    Dec 2, 2004
  3. Bob Gailer
    Replies:
    2
    Views:
    432
    Bengt Richter
    Jul 26, 2003
  4. Peter v.d. Berger

    Matching filenames with typos

    Peter v.d. Berger, Dec 4, 2006, in forum: Perl
    Replies:
    1
    Views:
    1,874
    Jim Gibson
    Dec 5, 2006
  5. Wolfgang Nádasi-donner

    Typos in eigenclass - Changes in Ruby 1.9

    Wolfgang Nádasi-donner, Aug 3, 2007, in forum: Ruby
    Replies:
    0
    Views:
    154
    Wolfgang Nádasi-donner
    Aug 3, 2007
Loading...

Share This Page