@Jeffrey, bpython is a bit unstable and crash-prone but I prefer it over Ipython.
On Sat, Feb 6, 2010 at 7:45 PM, Jeffrey Jose <jeffjosej...@gmail.com> wrote: > [ caution, huge email follows ] > > Hey Senthil, > I was under the impression that everyone here used and loved IPython. Boy, > was I wrong. > I wont attempt to convince you folks why you should use IPython, but here a > few features that I love in IPython which are not there (or not very > obvious) in vanilla python interpreter. > > note: I'm using ">>" for prompt, you can always customize your IPython > interpreter. > > *Tab completion*. I cant live without it. > bpython supports tab-completion > >> import sys > >> sy<TAB> > >> sys.<TAB> > sys.foo sys.bar sys.baz > > >> sys.getsi<TAB> > >> sys.getsizeof > > *Documentation* and *Function Signature* > bpython supports these features > >> sys.getsizeof? > *Type*: builtin_function_or_method > *Base Class*: <type 'builtin_function_or_method'> > *String Form*: <built-in function getsizeof> > *Namespace*: Interactive > *Docstring*: > getsizeof(object, default) -> int > > Return the size of object in bytes > > *Source Code* > >> import multiprocessing > >> multiprocessing.os? > *[Doc, Function Signature etc]* > > >> multiprocessing.os?? > *[opens the source code if you wanna browse around]* > > > Those are the top 3 things that I love about IPython interpreter. And ever > since I found them, I haven't gone back to vanilla python interpreter. > > Senthil wrote, > > * I am really not sure as how using IPython from pdb can help during > debugging? I tried it, I loose all the pdb's capabilities when I enter into > the IPython shell. How do people normally use it? > * > > Yes, you're right. You loose all capabilities of pdb when you're in IPython > (there's a solution, i'll get to that later) > Here's my typical IPython from pdb session for debugging. > > 1. Insert import pdb;pdb.set_trace() the place where I suspect the problem > is. Assume the very next line throws a huge error. > 2. Run the code, drop into pdb > 3. Invoke IPython from pdb > >> whos > # Shows all the variables in the current context > 4. Poke around a lil bit, see what's the values of variables are, etc etc. > Pretty normal stuff. Couple this with IPython's excellent introspective > power you can rip apart and dig each and everything. > >> import more_modules > >> try_different_things(); try_different_logic(); > 5. Execute the "next line" and expect it to throw the error. See the error, > if you want, retry the same line, try different arguments. Note: You havent > progressed a line at all, you're just trying out stuff at this moment > 6. Once you're done your bit, you *get out of IPython. Cntrl-D* > 7*. *Back in pdb, use all of pdb's power. Step in, Execute next line, set > more breakpoints, etc etc > 8. Hit "c" to proceed to next breakpoint. > 9. Repeat Steps 3 -> 8 > > I've never had to use print statements for debugging ever since I found > pdb. > With print, you can print only a couple of variables, with IPython (pdb > actually) you have access to the entire namespace. IPython just makes > working with the huge namespace a breeze. > > If you arent bored already, I'll explain a unique (weird ?) way I write > code > these days. > Normally, we have 2 windows open. One python interpreter and your fav text > editor. You try out stuff before to type it in your text editor. > Here's a different approach. > > Step 1: Start coding before you even try out a single bit on python > interpreter. > # myCode.py > import re > regex = re.compile(r'^b') > myList = ['foo', 'bar', 'baz'] > > for item in myList: > import pdb;pdb.set_trace() > > Step 2. Drop into pdb and then to IPython > Step 3. Try out your stuff *here*. You dont have to setup *myList*, *item, > regex *etc. You have everything ready waiting for you. > Step 4: > >> item > *'foo'* > > >> regex > *<_sre.SRE_Patten object at 0x123123>* > > >> regex.<TAB> > >> regex.mat<TAB> > >> regex.match? > *[read, find what it is, nope .. not what I wanted]* > > >> regex.<TAB> > >> regex.sea<TAB> > >> regex.search? > *[ah ha!]* > > >> regex.search(item) > >> Cntrl-D > > (pdb) c > > >> regex.search(item) > *<_sre.SRE_Match object at 0x123123>* > > *# phew, my re pattern works, awesome. I didnt have to setup dummy values > and then try it out etc.* > *# If re pattern didnt work the first time, I can make a new re patten and > try it out here. Again, I am not dealing with dummy values, but its the > actual values from the code -- foo, bar, baz (think if you're reading from > a > file, querying database etc.) work with real values, not dummy* > > *# Again, not knowing whether it is regex.search or regex.match to use > didnt > stop you from starting to code.* > * > *I call it breakpoint induced coding. Extremely helpful when you're > modifying someone else's code and you have no idea wht the heck all the > code > before this was doing. Insert a breakpoint (at the potential place you'd > edit/add code) and start from there. > > # someonesCode.py > import m1, m2, m3; > > call_function_1() > call_function_2() > do_extreme_stuff() > call_another_setof_functions() > > def do_extreme_stuff(): > s1 > s2 > potential_bug > s3 > > > Step 1. > s1 > s2 > *import pdb;pdb.set_trace()* > potential_bug > s3 > > Step 2: pdb -> IPython > >> whos > * #see what the variables are, what's the status of the program right now > etc* > > >> try_a_much_better_approach() > >> make_sure_it_works_and_doesnt_break_anything() > > Step 3: Go back to text editor and put in your stuff there. > Step 4: Peace. > > > If you're still reading, hope I havent confused you. > > > Jeff > _______________________________________________ > BangPypers mailing list > BangPypers@python.org > http://mail.python.org/mailman/listinfo/bangpypers > _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers