Note that ast.c still has a mix of tabs and spaces, because it
attempts to use four-space indents for more of the new code.

Reported by Mike Verdone.

are gone.

This duplicates the behavior whening normally printing exceptions.

Fixes bug 1569356, but at the cost of a minor incompatibility in
locals().  Add test that verifies that the class namespace is not
polluted.  Also clarify the behavior in the library docs.

Along the way, cleaned up the dict_to_map and map_to_dict
implementations and added some comments that explain what they do.

 * use %r instead of backticks since backticks are going away in Py3k
 * PyArena_Malloc() already sets PyErr_NoMemory so we don't need to do it again
 * the signature for ast2obj_int incorrectly used a bool, rather than a long

Don't use a fixed temporary name (gdbm).
Don't use our own temp name creation (dbm).
Should be backported to 2.5.

of some of the common builtin types.

Use a bit in tp_flags for each common builtin type.  Check the bit
to determine if any instance is a subclass of these common types.
The check avoids a function call and O(n) search of the base classes.
The check is done in the various Py*_Check macros rather than calling
PyType_IsSubtype().

All the bits are set in tp_flags when the type is declared
in the Objects/*object.c files because PyType_Ready() is not called
for all the types.  Should PyType_Ready() be called for all types?
If so and the change is made, the changes to the Objects/*object.c files
can be reverted (remove setting the tp_flags).  Objects/typeobject.c
would also have to be modified to add conditions
for Py*_CheckExact() in addition to each the PyType_IsSubtype check.

- clean up bogus use of the {datadescni} environment everywhere

I can't think of an easy way to test this behavior.  It only occurs
when the file system default encoding and the interpreter default
encoding are different, such that you can open the file but not decode
its name.

things cannot be raised or caught.

functions on platforms where the underlying system calls are available.

calling __import__.  This helps make the expected search locations for encoding
modules be more explicit.

One could use an explicit value for __path__ when making the call to __import__
to force the exact location searched for encodings.  This would give the most
strict search path possible if one is worried about malicious code being
imported.  The unfortunate side-effect of that is that if __path__ was modified
on 'encodings' on purpose in a safe way it would not be picked up in future
__import__ calls.