[banister]

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performance of the app. The approach taken by pry-rescue in contrast is to check for exceptions in a bounded portion of code (as many bounded portions as you want), so the slow-down is constrained to hot spots. This potentially makes pry-rescue OK for production use, something perhaps not suitable for ipython --pdb afaict.

[gingerlime]

you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`.

However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this is enhanced even more comparing rails to django (the stacks I used pry and ipdb with, respectively)...

I guess at least tab-completion slowness is down to the fact that by its nature ruby has far many more functions that can run on any object than python, and hence more options to tab-complete?

[banister]

hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.

[gingerlime]

I actually think it's mostly rails, not pry. I'm still new to rails and ruby, but somehow it feels much slower than django. Just loading the console feels like forever compared to the django shell.

However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice to see them! maybe that's what makes it feel slow to me.

[banister]

Possibly :) tab-completion will be substantially improved in an upcoming release :)

[gingerlime]

Great! looking forward to it. :)