You are theoretically right about not posting trivial patches, but as you can see, sometimes even a trivial patch elicits unexpected insights.  So I like to always post my patches, even the seemingly trivial ones.  Then if I don't get any responses, I figure it is OK to to ahead on the trivial ones :)

Of course, I don't do this 100% of the time.  This is especially true if there has been prior discussion, or sometimes discussion on IRC (although in the latter case I still may post the patch and always post summary of the IRC discussion).

As for the deprecation process. PendingDeprecationWarning was introduced for...I forget which feature it was.  Something that was going to be around for several releases, anyway.  And I think that feature wound up not getting removed until Python3, but I don't remember for sure.

Then for a short time we did start using it as you say, giving a three release deprecation cycle (pending, deprecated, gone), but that was before deprecation warnings were made silent.  PendingDeprecations were silent, you see, so using them one release early was a hack around the fact that DeprecationWarnings were *not* silent.

On the other hand I think we've gotten more strict about "needless" deprecations.  If there's no harm in leaving something in, we leave it in.  It's too bad Guido's comment wasn't noticed at the Python3 boundary; that is the perfect time to remove such cruft.  So doing a PendingDeprecationWarning to remind ourselves that this is something we want to remove in Python4 is also a reasonable approach.  Really, I think this is an area where our procedures and criteria are still a bit in flux...