paul rubin wrote:
> In that case, it works for what it is made for, so it really then is a separate question of whether implementing multisets properly is worthwhile.

Indeed, that seems to be the primary question to address. Personally, I don't have any strong opposition to including a multiset implementation in collections, I'm just not yet convinced they have enough widespread practical utility (that can't already be provided with Counter or a slightly modified version of it) to justify including them in collections.
 
> I dislike the concept of shovelling off basic functionality to 3rd party libraries.  The rejection of that philosophy (Python's old motto "Batteries included") is one of the things that attracted me to Python in the first place.  Though that value is mostly historical now, I'm sad about the loss.  It's impossible to write a large Ruby or Javascript (npm) application with 100s of third party modules, every one of which is an attack vector ("supply chain attack" is the current buzzword), and  whose implementations vary widely in quality and usability.

I can certainly sympathize with that sentiment of wanting to avoid excessive dependencies, and I think in general that we do still try to include more in the Python standard library compared to many other ecosystems. AFAIK, there's zero desire for the Python ecosystem to slowly turn into the "dependency hell" that NPM has become, with almost every library relying on a chain of minor 3rd party utilities.

However, rather than including everything that *might* be useful, the goal has been to include features that have substantial practical utility for a decent volume of users (and library maintainers), as long as they fit with the existing theme of a module (or are widely needed enough to justify a separate module) for a couple of primary reasons:

1) Making the stdlib modules as digestible as reasonably possible
2) Maximizing the ratio of practical benefit to implementation and long-term maintenance cost, which is especially important since development is voluntarily driven

Also, I would consider "batteries included" to still be a general goal, but it's practically impossible for the stdlib to fully cover what everyone would consider to be "basic functionality" while still maintaining its present quality. It's even more complicated by the fact that "basic functionality" will differ significantly depending upon who you ask, based upon what they personally use Python for and their unique experiences.

So, we tend to lean towards minimalism, focusing on implementing and improving features that have the most or strongest concrete use cases for a large volume of users. There are of course exceptions to this, such as features that are highly useful for a relatively small volume of users, but are difficult to implement a proper or optimized version. That has to be determined on a case-by-case basis though.