> Can a different example be chosen?

The traditional examples (urllib, socket, StringIO) grow context manager support as soon as the need becomes apparent.  So, that leaves only user-defined classes, third-party classes, generators, and cases where we already have a competing context manager that does something other than close.

A reasonable candidate is an sqlite connection.  It is a legitimate use case for contextlib.closing() since connections need to be closed after use, and because they already are context managers that do something different than closing (the commit or rollback transactions).

A generator example would work, but closing generators is a rare and esoteric need (not many people even realize than you *can* close a generator), so this would make a bad example.

A user defined class can add its own __enter__ and __exit__ to close if needed, so it isn't common to use contextlib.closing() on your own classes.   The primary use case is for third-party classes where you don't control the source code and a closing context manager isn't present; however, those make for bad examples because they aren't in the standard library (i.e. aren't familiar) and because the better maintained modules are also adding context manager support.

Out of all of these, only the sqlite connection example seems to be durable (won't go away) and familiar (in the standard library and not an exotic feature).

That said, I think it would be best to stick with the simplest and most familiar possible examples even if they are no longer needed.   The purpose of the example is to show how closing() works.  We can use the surrounding text to indicate that the example is no longer necessary and that the most common remain uses are to add closing() behavior to third-party code you don't control (if you do control the code, then adding CM support directly to the class would be preferable).