Various things in stdlib could benefit from the plugin system

[JukkaL]

These ideas are from #1240:

• re.findall
• sys.exc_info
• The built-in function pow (not math.pow)
• universal_newlines and subprocess.Popen
• dict(key=value) and dict.update with keyword arguments (the prior is currently special cased without a plugin)
• sum (works for anything that supports +)
• Parts of itertools and functools
• struct (could infer type from format string)

[ilevkivskyi]

sum (works for anything that supports +)

I would rather try supporting this by adding a protocol like Addable, (maybe also Comparable for sorted in Python 3). If that will not work, then this can be done using a plugin, but Addable and Comparable may be useful on their own.

[JukkaL]

Addable and Comparable may be hard to support in full generality. The complex semantics of reverse operator methods such as __add__ vs. __radd__ are one factor. When I looked at this earlier I came up with some tricky-looking corner cases but I can't remember all the details any more.

[ilevkivskyi]

I would add better support for enum to the list, see for example #3546
Or are we going to continue special casing Enum directly in code?

[JukkaL]

It's not a priority to get rid of the existing special casing for enum, but it would be better to use the plugin system for new features whenever possible. In the long term it may make sense to use a plugin for all or most of enum functionality.

[ilevkivskyi]

Here is an example where plugin for itertools.product will be useful: #3884

[hauntsaninja]

Closing because stale / protocols and literals. #7803 would be useful though!