Nobody is proposing taking the functional interface away (just as nobody is proposing to take the bisect module away).

Instead, the argument is:

- the heapq functions need to be combined with concrete storage to be useful

- a simple wrapper class that combines them with a given list (or other mutable sequence) is short and easy to maintain

- such a wrapper class is also useful in its own right for basic heap use cases

- so let's provide one in the collections module

The potential arguments against that are:

- this means yet-another-data-type in the collections module, so it will make the collections module harder to learn

- people will be confused as to whether they should use collections.Heap or the heapq functions

The risks of both of those outcomes seem low, since the main current source of confusion appears to be folks looking for a concrete "Heap" container type, and being surprised when they get told they either need to be build a DIY one from a list + the heapq functions, or else install a 3rd party dependency to get a preassembled one.

Cheers,

Nick.