triggered in situations that are not an error.

system calls.

native format, as void* (translated to Python int or long).
Also adds PyLong_FromVoidPtr and PyLong_AsVoidPtr to longobject.c.

manually generated).

of some paragraphs).

alias delimiter to ';;'.

compiler doesn't grumble.  Greg Stein's suggestion.

there's an __getinitargs__() method), if a TypeError occurs, catch and
reraise it but add info to the error about the class name being
instantiated.  This makes debugging a lot easier if __getinitargs__()
returns something bogus (e.g. a string instead of a singleton tuple).

for callit, used by the after() command.  This can happen when the
callback deletes the window.

initialization of class exceptions.  Specifically:

init_class_exc(): This function now returns an integer status of the
class exception initialization.  No fatal errors in this method now.
Also, use PySys_WriteStderr() when writing error messages.  When an
error occurs in this function, 0 is returned, but the partial creation
of the exception classes is not undone (this happens elsewhere).

Things that could trigger the fallback:

    - exceptions.py fails to be imported (due to syntax error, etc.)

    - one of the exception classes is missing (e.g. due to library
      version mismatch)

    - exception class can't be inserted into __builtin__'s dictionary

    - MemoryError instance can't be pre-allocated

    - some other PyErr_Occurred

newstdexception(): Changed the error message.  This is still a fatal
error because if the string based exceptions can't be created, we
really can't continue.

initerrors(): Be sure to xdecref the .exc field, which might be
non-NULL if class exceptions init was aborted.

_PyBuiltin_Init_2(): If class exception init fails, print a warning
message and reinstate the string based exceptions.

and without a message number argument: the argument was called 'msg'
but the code expected it to be called 'which'.  In line with the other
methods, I've renamed the argument to 'which', and adapted the doc
string not to refer to 'msg'.

This makes it possible to accept that on Linux %w returns "01" instead
of "1", for example.

(Jack Jansen and/or Just van Rossum)

discovered by Marc Lemburg.

changed to "LONG_LONG_hash" in the list of forward decls).  Discovered
by Jason Harper.

pdb.doc		Updated to reflect better the various changes.

pdb.py  Uses the Breakpoint class so one can enable/disable breakpoints,
	set temporary ones, set ignore counts, and conditions.  The last
	can be set using the 'b' command
		b 243 , i>4		( b 243,i>4 if you are space adverse)
	or with the condition command so conditions can be changed
	for a particular breakpoint.

	Breakpoints are numbered from 1 on, and if a breakpoint is deleted,
	the number is not reused.  All the breakpoint handling commands
	refer to breakpoints by number.  To be consistent, the clear command
	does so as well, which is the one change from the original pdb that
	is not transparent.  Thus only the breakpoint command 'b' uses a
	line number or file:line or method.  You can also give
		b whrandom.random    and the method will be searched for along
	sys.path.  This is implemented with an 'egrep' command and so
	is not as portable as it might be.  [ see  lineinfo() and
	lineinfoCmd ]

	Breakpoints cannot be set at a line that is blank or a '#' comment
	or starts a triply quoted comment.  This is because I would like
	this behavior in my DDD interface and think it reasonable for
	pdb as well.  It can be removed readily, however as it is all
	incorporated in the routine checkline().  If one attempts to
	set a breakpoint at a 'def' line, the breakpoint is automatically
	moved to the first executable line after the 'def'.  This too is
	in checkline().

	do_EOF() returns zero so typing an end-of-file character as a command
	does nothing.  'quit' does the quitting.

	The routine defaultFile() is present so as to preserve the current
	pdb behavior and yet allow me to override it in pydb.

	There's some code in lineinfo() that is probably mainly useful only
	for pydb and if you prefer, much up to the comment "Best first guess"
	could be removed.

	Keith Davidson provided the code for handling $HOME/.pdbrc and
	./.pdbrc, and it has been incorporated.  He also provided the
	alias handling routine.  I modified it a bit so it could live
	nicely in precmd().  He and I have been in contact; he has the
	new pdb (and pydb) with his code incorporated.  He also asked
	about the possibility of allowing multiple commands on one
	line, such as step;step  or s;s  or with an alias such as
		alias ct tbreak %1 ; continue
	and since it was so easy, that's in place as well.  It's a simple
	'split the line at the first ";"' operation and puts the second
	half in the command queue (self.cmdqueue).  This has the unfortunate
	effect of destroying a line like   print "i: "+i+"; j: "+j
	but either there's a simple way to deal with this, or my attitude
	will remain that pdb is a debugger, not a compiler/parser/etc.
	An alias like   alias 4s  s;;s;
	will work because the adjacent and trailing ";" act like a <cr> which
	repeats the last command.  Of course, either s;s;s;s or s;;;  would be
	a bit more sensible.

	The help commands have been updated.

bdb.py  now has a class definition called Breakpoint along with
	associated methods.  There's no reason why this class has to
	be there; if you prefer it elsewhere, 'tis easily done.

(Minor reformatting by GvR; e.g. moved Breakpoint's doc string to
proper point.)

cmd.py  has incorporated the changes we discussed a couple of weeks ago
	(a command queue, returning line from precmd, and stop from postcmd)
	and some changes to help that were occasioned because I wanted to
	inherit from pdb which inherits from cmd.py and the help routine
	didn't look for commands or the associated help deeply enough.