[Tutor] IDEs

[Steven D'Aprano]

Josep M. Fontana wrote:

>> Don;t run your code inside the IDE except for testing. IDEs are
>> Development Environments, they are not ideal for executing production
>> code. Run your file from the Terminal command prompt directly.
> 
> I thought the code was not run inside the IDE but it was run by Python
> independently, that is, the IDE just provides an interface.
> When I run code from within Eclipse (the IDE I'm starting to use) I
> can see a Python process in my process monitor. The process for
> Eclipse is consuming very little CPU.

I don't know about Eclipse specifically, but I understand that IDEs can 
often mess with the Python environment. E.g. they might change settings, 
add wrappers around functions to change the behaviour, install import 
hooks, change stdin and stdout, etc.

Personally, I don't think IDEs are necessary under Linux (although 
Windows users might find them more useful, due to the otherwise poor 
development tools available). I haven't used an IDE since THINK Pascal 
and Hypercard in the early 1990s -- I've looked at them, but the 
learning curve always seems far greater than the benefit.


> So, what is the advantage of running the file from Terminal? I can see
> only disadvantages:
> 
> a) it is slower since I have to type $python filename.py (ok, this
> takes very little time but clicking a button or typing a key shortcut
> to execute the code takes less time)

If you're repeatedly running the file, it takes even less time to just 
hit UP-ARROW to get the last-used line, then ENTER to execute it.

My usual working technique is:

I have an editor and a terminal open. The terminal has at least two tabs 
open. One tab is for the shell, where I run `python filename.py`. The 
second tab is for running an interactive Python shell. I run the script 
from one tab, and see if it works:

$ python filename.py

After the first time, I just hit UP ARROW and ENTER.

If it doesn't work, nine times out of ten I can see why just from the 
failure. I fix that bug in the editor, and run it again. Repeat until no 
more bugs.

The other nine times out of ten *wink* I need to do debugging, and I 
swap tabs and work in my interactive Python interpreter.

import filename  # first time only
reload(filename)  # all subsequent times

# test something:
filename.function_that_isnt_working(some_useful_data)

(I keep meaning to learn how to use the Python debugger, but honestly, I 
haven't needed it yet. You can go a long, long way with a few print 
statements.)

Notice that this is a very good reason for breaking your programs up 
into small, single-purpose functions. It makes it simple to isolate 
problems into a small part of your program.

Occasionally, when the environment gets too full of testing gunk, I exit 
the interpreter, and then immediately start it up again.

Also, I'm a big believer in test-driven development. I must admit though 
I'm not so pedantic to write the tests first, but for anything except 
quick-and-dirty scripts, I make sure that *every* function in my 
program, without exception, has a test to ensure that it works 
correctly. So I'll often have a third tab open for running my test 
suite. I use a mix of doctests and unit-tests. Here's an example from a 
project I'm working on at the moment:

[steve at sylar tests]$ python3 main_test.py
Doctests: failed 0, attempted 80
WARNING: No example text file found.
Running unit tests:
...............................................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 255 tests in 0.491s

OK
No garbage found.
[steve at sylar tests]$

If I see that, I know everything is working correctly (to the extent 
that everything is covered by tests). Each dot in the output represents 
  one test. A dot means the test passes, E means it has an error, and F 
means the test failed. If there are any errors or failures, a full 
diagnostic is printed.

Of course, it's a bit more work up front to write the tests, but:

(1) it pays off a dozen times over in the long run;

(2) the discipline of writing functions that are easy to test forces you 
to use good programming practice, avoid bad habits, and helps you design 
the program to be easy to maintain and debug; and

(3) if you want your work to be included in the standard library, you 
MUST have a full test suite.



-- 
Steven