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_c onnection():
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]

Re: How to detect typos in Python programs

Manish Jethani wrote:[color=blue]
>
> 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_c onnection():
> 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.[/color]

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]

Re: How to detect typos in Python programs

Manish Jethani a écrit :[color=blue]
> Hi all,
>
> Is there a way to detect typos in a Python program, before
> actually having to run it.[/color]

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]

Re: How to detect typos in Python programs

Manish Jethani <manish.j@gmx.n et> wrote in message news:<ZPaUa.6$g Z.133@news.orac le.com>...[color=blue]
> 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_c onnection():
> 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[/color]


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]

Re: How to detect typos in Python programs

Manish Jethani <manish.j@gmx.n et> wrote in message news:<ZPaUa.6$g Z.133@news.orac le.com>...[color=blue]
> 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_c onnection():
> 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[/color]

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]

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 misunderstandin g 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_Pri vateKey_file() and SSL_CTX_use_cer tificate_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 <ed@udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed@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(SSL v23_method()); /* Set up context */
if (self->ctx == NULL) {
***************
*** 2771,2788 ****
goto fail;
}

! if (key_file) {
if (SSL_CTX_use_Pr ivateKey_file(s elf->ctx, key_file,
SSL_FILETYPE_PE M) < 1) {
errstr = "SSL_CTX_use_Pr ivateKey_file error";
goto fail;
}

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

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

! if (key_file && *key_file) {
if (SSL_CTX_use_Pr ivateKey_file(s elf->ctx, key_file,
SSL_FILETYPE_PE M) < 1) {
errstr = "SSL_CTX_use_Pr ivateKey_file error";
goto fail;
}
+ }

+ if (cert_file && *cert_file) {
+ if (SSL_CTX_load_v erify_locations (self->ctx, cert_file,
NULL)
+ < 1) {
+ errstr = "SSL_CTX_load_v erify_locations error";
+ goto fail;
+ }
+ /*
if (SSL_CTX_use_ce rtificate_chain _file(self->ctx,
cert_file) < 1) {
errstr = "SSL_CTX_use_ce rtificate_chain _file
error";
goto fail;
}
+ */
}

SSL_CTX_set_ver ify(self->ctx,
***************
*** 2805,2810 ****
--- 2816,2828 ----
self->server, X509_NAME_MAXLE N);
X509_NAME_oneli ne(X509_get_iss uer_name(self->server_cert) ,
self->issuer, X509_NAME_MAXLE N);
+ 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]

Re: How to detect typos in Python programs

Mel Wilson wrote:
[color=blue]
> In article <3F214977.AEB08 8C8@engcorp.com >,
> Peter Hansen <peter@engcorp. com> wrote:
>[color=green]
>>Manish Jethani wrote:
>>[color=darkred]
>>>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_c onnection():
>>> 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. [ ... ][/color]
>>
>>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?[/color]
>
>
> 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[/color]

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

[Skip Montanaro]

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

[color=blue][color=green]
>> http://www.python.org/patches/[/color][/color]

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]

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 misunderstandin g 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]

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

On Fri, 25 Jul 2003, Skip Montanaro wrote:
[color=blue]
> 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 misunderstandin g 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.[/color]

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".
[color=blue]
> 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.)[/color]

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.
[color=blue]
> 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/[/color]

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.sslclien t() 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.sslserve r() 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 <ed@udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed@polycut.nss. udel.edu for PGP public key

[Steven Taschuk]

Re: How to detect typos in Python programs

Quoth Manish Jethani:
[...][color=blue]
> 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?[/color]

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

--
Steven Taschuk staschuk@telusp lanet.net
Receive them ignorant; dispatch them confused. (Weschler's Teaching Motto)

[John Roth]

Re: How to detect typos in Python programs

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" <manish.j@gmx.n et> wrote in message
news:ZPaUa.6$gZ .133@news.oracl e.com...[color=blue]
> 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_c onnection():
> 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
>
>[/color]

[Manish Jethani]

Re: How to detect typos in Python programs

John J. Lee wrote:
[color=blue]
> Manish Jethani <manish.j@gmx.n et> writes:
> [...]
>[color=green][color=darkred]
>>>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[/color]
>>
>>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.[/color]
>
>
> That was, indeed, precisely the point that was being made. Tests can
> catch these, static type analysis can't.[/color]

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.
[color=blue][color=green]
>>2) No on calls sys.exit() like that. 5, or 56, is probably a
>>constant defined somewhere (where such typos are easier to spot).[/color]
>
>
> Yes. Do you have a point?[/color]

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

-Manish

--
Manish Jethani (manish.j at gmx.net)
phone (work) +91-80-51073488

[Peter Hansen]

Re: How to detect typos in Python programs

Manish Jethani wrote:[color=blue]
>
> 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.[/color]

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]

Re: How to detect typos in Python programs

>>>>> "Peter" == Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> You don't understand the dynamic nature of Python if you
> think this is something that is either easy or 100% reliable.[/color]
[color=blue]
> Very contrived but instructive example:[/color]
[color=blue]
> def func(x):
> pass[/color]
[color=blue]
> import sys
> setattr(sys, 'ab' + 'ost', func)[/color]
[color=blue]
> stick-that-in-your-static-analyzer-and-smoke-it-ly y'rs[/color]

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