[Django Design] Inline debugging

[Sameer Rahmani]

Hi,

i was working in a project with a very complex logic, and i mixed up
with logical problems in the code. i used some debugging methods and
tools like ipdb, pdb.set_trace(), django-command-extension and etc. but
at last i end up with a little django patch #15249.

that patch provide a easy way to debug django code at the exception
raise time. i discussed about the inline debugging idea in irc developer
channel with some cool guys :D, and i decided to post this mail to
share the idea with others and get their ideas.

what does #15249 patch do?

it run a pdb or ipython shell when an exception raised with the
namespaces of raised trackback, (if settigns.INLINE_DEBUGGER set to
correct value), so it will be very easy to test some code.

why don't you use:

* pdb.set_trace()?
because i have to write some code in each module that i want to debug
and also i can't test some code snippet in the runtime env (as far as i
know)

* ipdb?
same as pdb and its and external module and i cant expect my friend to
install that too.

* django-command-extension?
it's an external tool too, its very cool but don't have some of ipython
feature like code completer.

#15249 patch is a little and lazy code, but it will be a good idea for
django to provide such functionality.

what's your idea about it ?

i know, i talk to much :P

[Russell Keith-Magee]

My biggest problem with this proposal is that it plants itself in the
main HTTP stack. That means it's in the code path when you deploy your
code into production.

I have no objection to the idea of making it easier to debug problems
when they occur, but it should be constrained to the development
server.

Better still, it should be something that can be implemented as an
entirely external tool, accessing a hook provided by the development
server. I don't know what that hook would look like exactly, but in
general, adding hooks is an easier sell than adding settings to
enable/disable functionality.

Yours,
Russ Magee %-)

[Sameer Rahmani]

Hi Russell

that patch is just a lazy code as i said before, but the idea will implements in better ways. it will be a good idea to use such code in development web server as an option. so user can easily use it, but using hooks and building and external tool is not a good way to deal with debugging matter, (in my point of view),

why?

because internal debugging facilities is important parts of a framework, the problem with external tools is that user have to do extra work to use them, but using an option like "python manage.py runserver --debug" is not a big deal.

thanks ;)

[Alex Kamedov]

Hi,

I think this is a good idea! 

+1 for "python manage.py runserver --debug" 

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--

Alex Kamedov

skype: kamedov    www: kamedov.ru

[Russell Keith-Magee]

That's fine, and I can agree with the sentiment -- but it's also not
what you included in your patch. I can only comment effectively on
code that I can actually see.

I would also point out that a hardcoded solution allow for exactly one
solution -- the solution you provide. However, if you provide a hook,
the entire community can collaborate to build bigger and better tools
that exploit that hook. That doesn't preclude shipping an
out-of-the-box, easy-to-use tool that exploits the same hook.

Yours,
Russ Magee %-)

[Sameer Rahmani]

Hi Russel

at first thanks for consideration. I post that patch just because
providing a little background about idea for other, also i know that
that patch is not well written code. So it will be nice to talk about
the main idea not about that patch.

I think hooks are a useful for development. If django provide a hook
facility (i think django does not have such thing right now, but i'm not
sure) something like elisp hooks, django development process will
improve.

but at last i think runserver can have some hooks that allow users to
change that by his/her choices but django can have its own inline
debugging tools build upon those hooks internally.

[Matteius]

What I want to see (and possibly the closest I've seen it with was a
video on the django_command_extensions) is an interactive debugger
built into my test-dev server so I can have break pts, switch logic
values in place, etc. dynamically on the test-dev server.

-Matteius

[sirex]

I agree with idea, but wish, that it would be implemented not only in
runserver, but also in test command:

$ python manage.py runserver --debug
$ python manage.py test --debug

I really missing this functionality, which is implemented and works
very well in nose:

http://packages.python.org/nose/plugins/debug.html

Now ~60% of the time, when an exception is raised and it is not clear
what caused it, I need to modify code and add ``import ipdb;
ipdb.set_trace()`` statement and run tests or refresh page again. If
ipdb would be launched automatically when exception is raised, it
would save a lot of time..

[Benjamin Wohlwend]

Hi,

On Thu, Feb 10, 2011 at 8:44 AM, Matteius <matt...@gmail.com> wrote:
>
> What I want to see (and possibly the closest I've seen it with was a
> video on the django_command_extensions) is an interactive debugger
> built into my test-dev server so I can have break pts, switch logic
> values in place, etc. dynamically on the test-dev server.
>

Have you guys looked at django-extensions[1] `runserver_plus` together
with Werkzeug's debugger[2]? On an exception, the error page provides
an interactive console on every level of the stack trace. No need to
modify Django, it just works(tm).

Regards,
Benjamin

[1]: https://github.com/django-extensions/django-extensions
[2]: http://werkzeug.pocoo.org/docs/debug/

[Gabriel Hurley]

I'm not a fan of one-size-fits-all debugging tools. The last several replies clearly show the variety of preferences people have for the already-existing options. Adding a setting that allows you to replace the debugging module also implies the replacement modules support a common API, which may not be true in plenty of cases.

If we can make changes that make integration easier for the great 3rd-party tools that are out there, that'd be excellent. I'm not sure what the current pain-points are for the developers of those tools off the top of my head, however.

The concept of the feature is great, and I do like the idea of having a command line flag to enable it, but the solution on that ticket doesn't really do it for me overall. Getting more consensus on what would make integrating these tools easier would be a good place to start, IMHO.

All the best,

    - Gabriel

[Alex Kamedov]

`runserver_plus` from django-extensions together with Werkzeug's debugger is a great tools,

but ipython console is more greater! Usualy than I work with site on dev server, I have already 

opened in IDE the project sources.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Sameer Rahmani]

Hi again

@benjamin
Django-command-extension is a really great tools but ipython is a robust
python shell with internal debugger autho completer and some many
features, there are many situation that runserver_plus does does not
come handy, also terminal is a great friend of a developer you have
terminal all time so you can always access a great ipyhton shell.

@Gabriel
as i told before that ticket and patch is just a lazy code that i write
to find my product problem and not the main solution, writing a inline
debugger need more consideration and a well design code.

i think debugging facilities help django user and developer to think
about there product and code not about solving problems and confusing
bugs.

A great framework should have a great development environment.