Java has an exception called IllegalStateException. It is very useful for signaling "what you did would have been OK, but right now I can't do it." Python does not have a counterpart, but I think it should.

For example, if you have a Python RDBMS-binding and you call db.select() before calling db.connect() it could raise a IllegalStateError (or maybe a subclass of it) that says 'IllegalStateError: "Must be connected to perform queries"'. 

Or for another example, take the Thread.start() function. Currently, if you call myThread.start() twice it will raise an AssertionError. That's no good because the result is undefined if you run python with -O. See Bug #904498 and Patch #1676820 (Martin v. Löwis comment). IllegalStateError should fit perfectly here:

>>> t = threading.Thread()
>>> t.start()
>>> t.start()
Traceback (most recent call last):
  ...
IllegalStateError: thread already started

In principle this is a good idea -- currently there's no guideline what to raise in such a situation.
Some libraries raise RuntimeError (probably a new exception should be made subclass thereof), some
do assertions, some raise custom exceptions.

However, for this to be a complete patch, you'd have to find all those places where IllegalStateError
would be appropriate. Also, switching to it would be a Py3k thing, provided that this breakage is
suffered by python-dev.

In any case, I think you should bring it up on the python-3000 mailing list -- otherwise this will
never be decided upon.

Georg, do you think that I should change the patch so that IllegalStateError sublcasses RuntimeError instead? 

Changing exceptions in the Standard Library to IllegalStateError would be part 2 of the patch. I don't think that should cause any trouble - only exceptions like AssertionError or base Exceptions would be changed. That's why I hope it can go into python 2.x. But bringing it up on the mailing-list is still required I guess.

Guido, would you pronounce on this?  I think the existing framework is fine and adding a new standard exception would be unnecessary clutter.

Following Raymond's advice, I'm rejecting this.  We don't need a lot of different standard exceptions for use by application code; it's better for libraries and modules to define their own exceptions.  RuntimeError is already a compromise -- it's mostly meant to save quick-and-dirty code from having to define exceptions, and to avoid the mistake of raising Exception().  (Some use of RuntimeError in the standard library notwithstanding.)