paul rubin <[email protected]> added the comment:
Kyle, thanks, I saw your comment after posting my own, and I looked at
Raymond's mailing list post that you linked. I do think that "completing the
grid" is a good thing in the cases where it's obvious how to do it (if there's
one and one obvious way, then doing it that way should work), and having
missing combinations in the grid is also a form of interface complexity (expect
subset to work, find that it doesn't, and implement some hack). Also it seems
to me that sets, dicts, bags are basic data objects in many languages these
days, without a lot of design space to move around in. So we don't have to
worry much about constraining future choices. We could just look at Smalltalk
or Ruby or whatever and just do what they did.
However, that is philosophical. I did learn from Raymond's message that
Counter doesn't really attempt to be a multiset implementation. 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. (That's as opposed to
saying we already have a multiset implementation but some functionality is
missing from it).
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 looked at the docs for Ruby's multiset gem
(https://maraigue.hhiro.net/multiset/) and they are partly in Japanese. Python
has until the past few years managed to keep away from that kind of thing.
----------
_______________________________________
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
