How to detect typos in Python programs

[Manish Jethani]

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) [phone]

[Peter Hansen]

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

[Alexandre Fayolle]

Manish Jethani a écrit :

Hi all,

Is there a way to detect typos in a Python program, before
actually having to run it.

You may want to give a look at pylint (http://www.logilab.org/pylint/)

--
Alexandre Fayolle
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Développement logiciel avancé - Intelligence Artificielle - Formations

[aj coon]

Manish Jethani <ma******@gmx.net> wrote in message news:<ZP************@news.oracle.com>...

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

[Richard]

Manish Jethani <ma******@gmx.net> wrote in message news:<ZP************@news.oracle.com>...

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

[Ed Phillips]

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 <[e-mail]> University of Delaware [phone]
Systems Programmer III, Network and Systems Services
finger -l [e-mail] 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);

[Manish Jethani]

Mel Wilson wrote:

In article <3F***************@engcorp.com>,
Peter Hansen <pe***@engcorp.com> 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) [phone]

[Skip Montanaro]

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]

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

[Ed Phillips]

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 <[e-mail]> University of Delaware [phone]
Systems Programmer III, Network and Systems Services
finger -l [e-mail] for PGP public key

[Steven Taschuk]

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 st******@telusplanet.net
Receive them ignorant; dispatch them confused. (Weschler's Teaching Motto)

[John Roth]

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" <ma******@gmx.net> wrote in message
news:ZP************@news.oracle.com...

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) [phone]

[Manish Jethani]

John J. Lee wrote:

Manish Jethani <ma******@gmx.net> 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) [phone]

[Peter Hansen]

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

[Ganesan R]

>>>>> "Peter" == Peter Hansen <pe***@engcorp.com> 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

[David Bolen]

Manish Jethani <ma******@gmx.net> 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