[Patches] [Patch #100947] increase control and default size of pdb traceback display

[noreply@sourceforge.net]

Patch #100947 has been updated. 

Project: 
Category: library
Status: Postponed
Summary: increase control and default size of pdb traceback display

Follow-Ups:

Date: 2000-Aug-13 20:15
By: nowonder

Comment:
There is a detailed description in the patch.
-------------------------------------------------------

Date: 2000-Aug-15 10:55
By: tim_one

Comment:
Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once <wink>.  Please review or pass on to someone else.
-------------------------------------------------------

Date: 2000-Aug-17 12:36
By: gvanrossum

Comment:
I like the idea fine, but the command name "scaletb" sucks.  Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in.

(Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-)

Possibly a better name could include "control" (or an abbreviation) instead of "scale"?
-------------------------------------------------------

Date: 2000-Aug-21 16:59
By: tim_one

Comment:
Ken, are you going to repsond to Guido's comments?  And do you want developer privileges?
-------------------------------------------------------

Date: 2000-Aug-27 09:57
By: klm

Comment:
Sorry about not responding more promptly.  Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through.  It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it.  I do seem to have cvs ssh access, now, and have an alternate name to suggest.  I'd be happy to arrive at some agreement on a name and then check in the changes.

My current suggestion is 'limit_tb', with no abbreviation.  I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'.  I can see objections to this, and am open to other suggestions.  (If you insist on 'control_tb' or somesuch, fine.)

Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands.  

First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place.  And cumbersome.

Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break").  Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above.

Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit".  That seems much too elaborate for a single option.  It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session.  While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it.

So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach).  (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...)

Ken
-------------------------------------------------------

Date: 2000-Aug-31 14:36
By: jhylton

Comment:
Ken has disappeared <wink>

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470