[Baypiggies] Possible future meeting topic

[Shannon -jj Behrens]

On Sun, Oct 19, 2008 at 9:04 PM, Stephen McInerney
<spmcinerney at hotmail.com> wrote:
> My personal order of preference:
>
>> * Using the profile module
> +1 Definitely, but I want to know how to go all the way to coloring hotspots
> in my source code
> in (say) Eclipse IDE, i.e. a high-productivity low-overhead flow judiciously
> using profiling only as and where needed, and mainly to shift stuff out of
> the inner loop. And when do I decide to either go to Psyco JIT, or recode
> the inner loop in C++ and wrap it for Python?

A while ago, Drew talked about using KCacheGrind for profiling.
That'd be a nice little addition.  I haven't tried it, so I can only
talk about normal profiling.

>> * Using IPython
>> * Using nose, nose tests, and doctest
> +1 to both, Fernando Perez (ipython creator) may touch on iPython next month
> anyway when
> he talks on Scientific Python. FYI NumPy uses nose and Sphinx-based
> documentation.
> (see p24, "The State of SciPy"
> 2008, http://conference.scipy.org/static/wiki/stateofscipy.pdf )
>
>> * Using pdb
> 0.5 don't really care. Do people use this much on real systems for actual
> debug?
> Asserts, logging and trusty old print statements have always done it for me.
> (Will pdb do multithreaded? etc.)

Coding in the shell is great, but sometimes coding in the debugger is
like coding in the shell but with all the setup already taken care of
;)  It's a good trick when you want to code in the shell, but you're
writing a Web app that requires a full request, etc. and you need to
"look around" at all the data in the environ to figure out what to do.
 2 minutes looking around in pdb saves 20 minutes looking through
middleware documentation ;)

-jj

-- 
The safest way to do multithreaded programming is to put each thread
in its own process ;)
http://jjinux.blogspot.com/