That's it :-)

Logged In: YES 
user_id=31435

Probably not, Brian.  types.py largely exists just for 
backward compatibility now.  If you want the bool type, 
just say "bool"!

>>> bool
<type 'bool'>
>>> type(bool)
<type 'type'>
>>> isinstance(True, bool)
True
>>>

Like also int, str, long, file, dict, ... in 2.2, what used 
to be builtin functions for constructing an object of a 
given type are now *the* type objects themselves, acting as 
constructors for objects of their types.  There's no reason 
to add them to types.py too.

Assigning to Guido in case he disagrees.

Logged In: YES 
user_id=108973

I understand your point about isinstance being the one true 
way of doing things now. 

But I don't understand what your code is trying to 
demonstrate.

As long as this works:
>>> type(True) is type(bool(1))
True
>>> type(1) is type(bool(1))
False

I don't see why StringType should be in types.py and 
BoolType shouldn't be.

Logged In: YES 
user_id=21627

You would never write

type(True) is type(bool(1))

Instead, you write

type(True) is bool

just the same way as you write

type("") is str

So in practice, there is no need to use the types module,
atleast not in a typical application, and for new code. All
the old code can continue to use the types module, likewise
code that needs to work across versions - but such code
would not expect types.BoolType to be present, either.

So I agree with Tim that this is not a bug.

Logged In: YES 
user_id=6380

StringType should be in types for backwards compatibility.
There's lots of existing (user and 3rd party) code that uses
types.StringType. There's zero code that uses
types.BoolType, and I want to keep it that way.