Jon, we usually try to avoid sweeping changes across the library and instead preference to focus on one module at a time (Guido calls this "holistic refactoring").  There is a risk of introducing bugs and of destabiliizing code that has sat untouched but working for a long time.

Also, as Serhiy and Steven have pointed out, there are sometimes subtle reasons to prevent the existing code.  For example, I find the original to be clearer in this example:

 - return list(set(item.name for item in self.list))		 +        
 + return list({item.name for item in self.list})

and the original to be both clearer and faster in this example:

 - return list(map(_convert, node.elts))
 + return [_convert(v) for v in node.elts]

In some cases, using "dict(...)" or "set(...)" is clearer about the intension or more readable because it is parallel to the surrounding code (such as the parallelism of successive line in ast.py).

In some cases such as _pydecimal we have a aversion to changing code that aspires to be backwards compatible across many versions.

That said, there are a few places where it might be worthwhile for making a change.  Converting to set literals is almost always a win:

 -    interesting = set(("include", "lib", "libpath", "path"))		 
 +    interesting = {"include", "lib", "libpath", "path"}

As Serhiy noted, in some places using map() would be an improvement, so we should look at doing a few of those (where there is a win in term of speed, space, and readability):

 - version_info = tuple([int(x) for x in version.split(".")])
 + version_info = tuple(map(int, version.split(".")))

Overall, I think most of these shouldn't be done, but I will mark a few where some change might be considered an improvement.  Steven or Serhiy are both welcome to veto any one of those.  Likewise, if the original author of the code is still active, they have a veto as well.  The status quo usually wins until we're refactoring a single module and make improvements while thinking about that module.

You picked a difficult first patch because you picked a topic that we usually avoid (wholesale sweeps through the standard library) and an area where deciding "what is best" involves subtleties with respect to clarity, parallelism with surrounding code, speed, clear intention, back compatibility, and how the original author thinks about the code.