> Therefore, I think it's important to cover the complete protocol 
> in the Generator ABC. I also think it's helpful to not require
> users to override throw() in a subclass, as they might not need it.

Sorry, but I think you're fighting the fundament nature of what the ABCs are supposed to do and I object to the patch going in as-is.  

Please either 
1) drop the throw() method entirely or
2) make throw an abstractmethod()

If it is an abstractmethod, the user is free to implement a throw() method that raises a NotImplementedError, but at least they will do so consciously rather than having it come-up expectedly.

When I teach engineers how to use the collections ABCs, they rely on the rules:

 * when building a class that inherits from an ABC,
   if you supply the required abstract methods,
   then the mixin method just work.

 * if an object passes the isinstance check, 
   then it is fair game to call any of the listed
   methods an expect it to work.

Until now, those rules were followed by all the ABCs.  I really don't want to break the basic contract of what the ABC is supposed to mean.