asaf ebgi <asafebgi(a)gmail.com> writes:
> Well, I am actually inspecting code from the tastypie django library -
> -So there is lots of code --But an example is below:
> In the Variables List:
> instance: User
> self: ForeignRelatedObjectsDescriptor
> | .related: RelatedObject
> superclass: <class 'django.db.models.manager.Manager'>
> (self is expanded)
> in the console I type:
> ['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
> '__get__', '__getattribute__', '__hash__', '__init__', '__module__',
> '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__set__',
> '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
> '__weakref__', 'create_manager', 'delete_manager', 'related']
>>>> getattr(self, 'related')
> <RelatedObject: app:profile related to user>
> ('related' appears in the Variables list)
>>>> getattr(self, 'delete_manager')
> <bound method ForeignRelatedObjectsDescriptor.delete_manager of
> object at 0x1bdaed0>>
> ('delete_manager' does not appear in Variables list -- Neither does
Can you try and see if this is fixed in git?
Tin Tvrtković <tinchester(a)gmail.com> writes:
> Pudb looks very interesting and useful. I'm having trouble, however,
> debugging multithreaded programs. For example, if I set a breakpoint in a
> method and execute that method in a separate thread, the breakpoint doesn't
> get triggered. Am I doing something wrong or is this simply not available
> right now?
Pudb is no better than pdb (Python's built-in debugger) in this
regard--in fact, it's built on the same machinery (bdb). See this PDF
for some tricks:
I'd be open to see pudb aimed at a less limited backend at some point,
but that's all we've got for now.
Pudb looks very interesting and useful. I'm having trouble, however,
debugging multithreaded programs. For example, if I set a breakpoint in a
method and execute that method in a separate thread, the breakpoint doesn't
get triggered. Am I doing something wrong or is this simply not available
Cheers, and thanks for pudb!
Fabien Meghazi <agr(a)amigrave.com> writes:
>>> > Sure, you can stick that breakpoint into
>>> > $HOME/.config/pudb/saved-breakpoints, in this format:
>>> Hey ! that's so cool, using this tip I can even add a key binding in
>>> vim in order to generate the breakpoint from the file I'm editing !
>> Cool. If you create a vim script that does that, please make a note of
>> it here:
> Hi Andreas,
> Remember this little chat about a vim plugin that would set/unset breakpoints ?
> A colleague of mine just did it :
> Now we have to find a way to make pudb watch this file in order to
> reload the breakpoint list.
> Do you have an idea if this is possible ?
I was half-way done coding this when I noticed that I don't like the
semantics of 'watching the file' at all. Suppose you've got two pudb
sessions running simultaneously. One exits, and writes the
'saved-breakpoints' file. Should the other one just throw away all the
breakpoints it knows about and use the ones from the instance that just
exited? Not really.
For the moment, I've made an undocumented 'Ctrl-r' shortcut in git that
reloads the file.