How to prevent Python applications from blowing up

drcouzelis · 2010-11-12 13:27:03

Have you ever been using a Python application and all of a sudden POW an exception occurs and a small stack trace appears? I have. Sometimes it crashes the application, and sometimes it continues running seemingly fine.

I started writing my first application in Python. I love it. But I think I've learned why those kind of "exception" errors exist. Python just seems to be... touchy.

My current work pattern is like this:
...make a pretty small change in the Python code...
...run and test it until it blows up...
...read the error message and fix it...
...run and test it until it blows up...
...read the error message and fix it...
...and repeat.

I'm worried because, as my application gets bigger and bigger, there's a LOT of testing I'll have to do for a comparatively small change.

My question is, as a programmer, what can I do to make sure my Python application won't blow up? Any advice, such as external applications, programming styles, and how to be more Pythonic is welcome.

Thank you.

(for background, I am a professional software developer, with a lot of experience in C, Objective-C, and Java)

linux-ka · 2010-11-12 14:24:29

Welcome to the world of Python!

What exactly to you mean by blowing up? The program just runs well but hangs up by time..or is there a reproduceable error in the code triggert by some event?

You can get rid of some exceptions (or make use of) by implementing

try:
     do some stuff
except <Error_event>:
    do some other stuff

.
You could also try using the pychecker. Kind of debugger for python, I guess...but I've never had the feeling it could help solving my problems.

Ramses de Norre · 2010-11-12 14:45:11

Exceptions occur because you've done something wrong, so I guess the only way to prevent them is to gain more experience with the language so that you don't need the exceptions to tell you that you're wrong.
Also for the testing, look into unit tests to automate the process of testing and to give you some more rigorous picture.

drcouzelis · 2010-11-12 14:45:21

linux-ka wrote:

Welcome to the world of Python!

Thanks. I never wanna leave.

is there a reproduceable error in the code triggert by some event? ... You could also try using the pychecker. Kind of debugger for python

Yes, this is the kind of error I meant. I didn't know about PyChecker. I think it will help me a lot. The description from http://pychecker.sourceforge.net/ explains how I was feeling quite well: "It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++".

I could also use help with this related question: I think many of my current problems come from variables being the wrong data type. In C, I would of course declare a variable as a specific type, such as "int". In Python, I try adding two variables that I think are "floats", and they accidentally end up being "strings". So, I end up doing a lot of "float(...)" casts. Is there a more Pythonic way to handle variable types?

drcouzelis · 2010-11-12 14:48:57

Ramses de Norre wrote:

Also for the testing, look into unit tests to automate the process of testing and to give you some more rigorous picture.

I think that's a great idea. You know, at first that sounded like a hassle, but now that I think about it, I think making an automatic test in Python would be quite easy.

I'm making a GUI application with wxPython. I'll try writing a function that calls all of my widget "handles" and stuff.

cebru · 2010-11-12 15:03:27

I assume you are using Object Oriented programming: Design your code so that is open for extension, but closed for modification.

http://en.wikipedia.org/wiki/Open/closed_principle

drcouzelis · 2010-11-12 16:10:30

cebru wrote:

Design your code so that is open for extension, but closed for modification.

Thank you for the suggestion, but I'm a little confused. How will that help me have fewer exceptions and stack traces in Python?

xl666 · 2010-11-12 20:43:58

As you say, the fact that Python is a dynamic typed language implies that some error checking previous to run the program, that are usual in static languages like c, aren't happening on python, this is normal. You just need to remember the Python way: you need to care about interfaces no types. The hole thing about the last statement is flexibility, a fundamental part of python. But at the same time types exist on python, ¿why?, because interfaces must to adhere to something.

I think the problem you refer as the need to cast a lot of float() is because you're getting user data as strings, but the problem essentially isn't because the objects are of different types, is because the interface meaning for '+' is different for srt and float so the cast is needed.

If you think that exist any possibility for a parameter to not adhere an interface, then use try/catch statements, but once you get the hole idea you'll realize that errors derived for unsupported interfaces or kinda will minimize a lot.

I hope this post help you, and excuse my bad english, regards.

Last edited by xl666 (2010-11-12 20:49:39)

drcouzelis · 2010-11-12 21:25:29

xl666 wrote:

As you say, the fact that Python is a dynamic typed language implies that some error checking previous to run the program, that are usual in static languages like c, aren't happening on python, this is normal. You just need to remember the Python way: you need to care about interfaces no types. The hole thing about the last statement is flexibility, a fundamental part of python. But at the same time types exist on python, ¿why?, because interfaces must to adhere to something.
I think the problem you refer as the need to cast a lot of float() is because you're getting user data as strings, but the problem essentially isn't because the objects are of different types, is because the interface meaning for '+' is different for srt and float so the cast is needed.
If you think that exist any possibility for a parameter to not adhere an interface, then use try/catch statements, but once you get the hole idea you'll realize that errors derived for unsupported interfaces or kinda will minimize a lot.
I hope this post help you, and excuse my bad english, regards.

Wow! You understand my situation exactly!

Thank you for the advice. I will clean my GUI code and the class I wrote. I will learn more about exceptions.

cebru · 2010-11-12 23:26:45

drcouzelis wrote:

Thank you for the suggestion, but I'm a little confused. How will that help me have fewer exceptions and stack traces in Python?

I was responding to this part of your post:

I'm worried because, as my application gets bigger and bigger, there's a LOT of testing I'll have to do for a comparatively small change.

If you use the open/closed principle, you will have an easier time locating new errors as they are most likely to happen with the new code you write to extend the current code base. If you have to change a lot of modules every time you add a new feature, errors can appear in a lot of different places in your code. Of course this principle cannot be used for everything, but I personally found it to be one of my favorite Object Oriented design principles and hoped it would help you. Hope it makes sense now.

But I can see how xl666's advice is much better

Last edited by cebru (2010-11-12 23:27:21)

drcouzelis · 2010-11-13 13:30:09

cebru wrote:

If you use the open/closed principle, you will have an easier time locating new errors as they are most likely to happen with the new code you write to extend the current code base.

Thank you, that is good advice. Since you mentioned it, I realized I am using the open / closed principle a little bit!

First, I made the GUI in wxGlade.

Next, I made a file with the functionality for the GUI that inherits the GUI classes from wxGlade.

So, I can make a change to the GUI and the functionality will be ok, and I can make a change to the functionality and the GUI will be ok.

Next, I think I'll review my code and make sure it follows the PEP 8.

3]) · 2010-11-21 18:00:27

Not sure if anyone stated it here, but the default python editor IDLE, comes with a 'debug' option, so you can go from definition to definition and fix these mistakes as you 'step' through the program.

Just start it in IDLE via Debug-Debugger, then open your program and run it.

drcouzelis · 2010-11-21 23:27:00

3]) wrote:

Not sure if anyone stated it here, but the default python editor IDLE, comes with a 'debug' option, so you can go from definition to definition and fix these mistakes as you 'step' through the program.

Wow! I didn't know Python had a default editor! And I certainly didn't know it was already installed on my computer. Thanks for the tip.

Just start it in IDLE via Debug-Debugger, then open your program and run it.

I ran IDLE and looked at all of its features. I'm sorry, I'm confused by the instructions you gave. What is Debug-Debugger?

I've been using PyChecker. It's been really helpful. Also, I think I'm just getting more experienced with Python programming in general, and that helps.

These tips have been great.

3]) · 2010-11-22 21:35:17

drcouzelis wrote:

3]) wrote:
Not sure if anyone stated it here, but the default python editor IDLE, comes with a 'debug' option, so you can go from definition to definition and fix these mistakes as you 'step' through the program.
Wow! I didn't know Python had a default editor! And I certainly didn't know it was already installed on my computer. Thanks for the tip.
Just start it in IDLE via Debug-Debugger, then open your program and run it.
I ran IDLE and looked at all of its features. I'm sorry, I'm confused by the instructions you gave. What is Debug-Debugger?
I've been using PyChecker. It's been really helpful. Also, I think I'm just getting more experienced with Python programming in general, and that helps.
These tips have been great.

I should have been more clear though.

In IDLE, when the IDLE python shell is open, there should be options to choose from the menu (File; Edit; Shell ; Debug; Options; Windows ; Help).

With Debug->Debugger I meant to go to the Debug menu, and click on Debugger to start the Debugger.
Hence, you can run your python program and actually start 'debugging'.

I thought Pychecker was meant to check vulnerabilities in the code? Will try that tool myself. ;-)

EDIT:pychecker does something similar to Debug, but instead of stepping through the code does it all in realtime.
Interesting.

Last edited by 3]) (2010-11-22 21:38:37)

namegame · 2010-11-23 20:31:13

You may also want to look into PyLint and pdb. They are also python debuggers with other features.

Dusty · 2010-11-24 16:43:08

My personal debugging tool of choice is IPython. pip install ipython and then put these lines in your code any time you need to introspect anything:

from IPython import Shell
Shell.IPShellEmbed([])()

You get a full interactive shell at that exact point in your code, so you can test variables, assign them, and execute anything. Press ctrl-d and it returns to running the program.

For testing, I recommend py.test and test driven development. Write tests that prove your code works, then write the code until the tests pass. When you modify your code, run the tests again to make sure you didn't break something (you probably did, but at least you'll know when it happens, instead of when a user reports a bug). py.test has a lot of extremely useful shortcuts to make writing tests fun. And it supports Python 3, Arch's default python interpreter.

If you need to debug concurrent programs or programs that are already running, winpdb is a useful tool. Don't let the name fool you, it's not windows-only.

Dusty

n0dl · 2010-11-25 13:35:45

If you haven't done so already, you may want to look into the unit testing module pytest (built in since 2.1 iirc). While it won't necessarily prevent your program from blowing up, it's comforting to know all of your prior code still works after making a change.

Arch Linux

#1 2010-11-12 13:27:03

How to prevent Python applications from blowing up

#2 2010-11-12 14:24:29

Re: How to prevent Python applications from blowing up

#3 2010-11-12 14:45:11

Re: How to prevent Python applications from blowing up

#4 2010-11-12 14:45:21

Re: How to prevent Python applications from blowing up

#5 2010-11-12 14:48:57

Re: How to prevent Python applications from blowing up

#6 2010-11-12 15:03:27

Re: How to prevent Python applications from blowing up

#7 2010-11-12 16:10:30

Re: How to prevent Python applications from blowing up

#8 2010-11-12 20:43:58

Re: How to prevent Python applications from blowing up

#9 2010-11-12 21:25:29

Re: How to prevent Python applications from blowing up

#10 2010-11-12 23:26:45

Re: How to prevent Python applications from blowing up

#11 2010-11-13 13:30:09

Re: How to prevent Python applications from blowing up

#12 2010-11-21 18:00:27

Re: How to prevent Python applications from blowing up

#13 2010-11-21 23:27:00

Re: How to prevent Python applications from blowing up

#14 2010-11-22 21:35:17

Re: How to prevent Python applications from blowing up

#15 2010-11-23 20:31:13

Re: How to prevent Python applications from blowing up

#16 2010-11-24 16:43:08

Re: How to prevent Python applications from blowing up

#17 2010-11-25 13:35:45

Re: How to prevent Python applications from blowing up

Board footer