Kyle Stanley <[email protected]> added the comment:
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.
----------
nosy: -veky
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue40411>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
