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) +91-80-51073488

[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

[Mel Wilson]

In article <3F214977...@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

Testing really is a Good Thing.

Regards. Mel.

[aj coon]

Manish Jethani <mani...@gmx.net> wrote in message news:<ZPaUa.6$gZ....@news.oracle.com>...

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 <mani...@gmx.net> wrote in message news:<ZPaUa.6$gZ....@news.oracle.com>...

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

[Bob Gailer]

consider:
use a regular expression to get a list of all the identifiers in the program
count occurrence of each by adding to/updating a dictionary
sort and display the result

program_text = """ def server_closed_connection():
session.abost()"""
import re
words = re.findall(r'([A-Za-z_]\w*)\W*', program_text) # list of all
identifiers
wordDict = {}
for word in words: wordDict[word] = wordDict.setdefault(word,0)+1 # dict of
identifiers w/ occurrence count
wordList = wordDict.items()
wordList.sort()
for wordCount in wordList: print '%-25s %3s' % wordCount

output (approximate, as I used tabs):

abost 1
def 1
server_closed_connection 1
session 1

You can then examine this list for suspect names, especially those that
occur once. We could apply some filtering to remove keywords and builtin names.

We could add a comment at the start of the program containing all the valid
names, and extend this process to report just the ones that are not in the
valid list.

Bob Gailer
bga...@alum.rpi.edu
303 442 2625

[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...@udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l e...@polycut.nss.udel.edu 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:

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 Jethani]

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. 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?

I get your point. But my program is basically open source, so I
release early and often, and I expect users to report bugs. BTW
a lot of big software houses I know of also do the same thing,
but their marketing departments like to put things in a
different way ("time to market", "beta release", and stuff like
that :-) ).

Call my release an alpha, beta or whatever. But I expect users
to report "real bugs", not typos. So I thought there should be
a better way to catch these things (I saw pylint and pychecker,
and they look good).

> 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.

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?

FYI: The program in question is msnp.py.
<URL:http://msnp.sf.net/>

thanks,

[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?

[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

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

[Bengt Richter]

On 25 Jul 2003 11:36:23 -0700, rsh...@midsouth.rr.com (Richard) wrote:
[...]

>
>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.
>

I'm afraid with that last line you just named a big obstacle
to more widespread adoption of unit testing ;-/

Regards,
Bengt Richter

[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" <mani...@gmx.net> wrote in message
news:ZPaUa.6$gZ....@news.oracle.com...

[Bengt Richter]

On Fri, 25 Jul 2003 12:20:57 -0600, Bob Gailer <bga...@alum.rpi.edu> wrote:

>--=======6B79482F=======
>Content-Type: text/plain; x-avg-checked=avg-ok-74704BF8; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 8bit

That's cool. If you want to go further, and use symbols that the actual program
is using (excluding comment stuff) try:

====< prtok.py >========================================================
#prtok.py
import sys, tokenize, glob, token

symdir={}

def tokeneater(type, tokstr, start, end, line, symdir=symdir):
if (type==token.NAME):
TOKSTR = tokstr.upper() #should show up for this file
if symdir.has_key(TOKSTR):
d = symdir[TOKSTR]
if d.has_key(tokstr):
d[tokstr] += 1
else:
d[tokstr] = 1
else:
symdir[TOKSTR]={ tokstr:1 }

for fileglob in sys.argv[1:]:
for filename in glob.glob(fileglob):
symdir.clear()
tokenize.tokenize(open(filename).readline, tokeneater)

header = '\n====< '+filename+' >===='
singlecase = []
multicase = [key for key in symdir.keys()
if len(symdir[key])>1 or singlecase.append(key)]
for key in multicase:
if header:
print header
print ' (Multicase symbols)'
header = None
for name, freq in symdir[key].items():
print '%15s:%-3s'% (name, freq),
print
if header: print header; header = None
print ' (Singlecase symbols)'
byfreq = [symdir[k].items()[0] for k in singlecase]
byfreq = [(n,k) for k,n in byfreq]
byfreq.sort()
npr = 0
for freq, key in byfreq:
if header:
print header
header = None
print '%15s:%-3s'% (key, freq),
npr +=1
if npr%4==3: print
print
========================================================================
Operating on itself and another little file (you can specify file glob expressions too):

[18:55] C:\pywk\tok>prtok.py prtok.py gt.py

====< prtok.py >====
(Multicase symbols)
tokstr:6 TOKSTR:4
NAME:1 name:2
(Singlecase symbols)
append:1 argv:1 clear:1
def:1 end:1 import:1 keys:1
len:1 line:1 open:1 or:1
readline:1 sort:1 start:1 upper:1
else:2 fileglob:2 has_key:2 items:2
multicase:2 n:2 sys:2 token:2
tokeneater:2 type:2 None:3 filename:3
glob:3 npr:3 singlecase:3 tokenize:3
d:4 freq:4 k:4 byfreq:5
for:8 if:8 in:8 key:8
header:10 print:10 symdir:11

====< gt.py >====
(Singlecase symbols)
__name__:1 argv:1 def:1
if:1 fn:2 for:2 import:2
in:2 main:2 print:2 sys:2
arg:3 glob:3

Regards,
Bengt Richter

[Bengt Richter]

On 26 Jul 2003 01:54:19 GMT, bo...@oz.net (Bengt Richter) wrote:
[code that got += line switched. needs change to increment after conditional print:]

--- prtok.py~ Fri Jul 25 18:52:53 2003
+++ prtok.py Fri Jul 25 19:58:24 2003
@@ -43,6 +43,6 @@

print header
header = None
print '%15s:%-3s'% (key, freq),

- npr +=1
if npr%4==3: print
+ npr +=1
print

Regards,
Bengt Richter

[John J. Lee]

Manish Jethani <mani...@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.

> 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?

John

[Manish Jethani]

John J. Lee wrote:

> Manish Jethani <mani...@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.

[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 <mani...@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