Re: A standard library Multiset implementation?
I am often driven to use, for example, itertools set(permutations(multiset, n))
Try the more-itertools package: https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.dist... from more_itertools import distinct_permutations from collections import Counter c = Counter('abracadabra’) print(list(distinct_permutations(c.elements(), 3)))
there is little if any solid evidence that they do what they claim to do (
The code in more-itertools is trustworthy. Also the docs have links to the source, so you can just read the code and let it earn your trust. Raymond
Thank you for your advice, Raymond, which I much appreciate. I have started to use the more_itertools package. I probably also need to take Counter() more seriously but I have shied away from it until now, fearing that it might be more focussed on 'counting' than on 'multiset operations' (i.e. such as the API here: https://multiset.readthedocs.io/en/stable/). Brian
On Sat, Aug 20, 2022 at 9:07 AM Brian Gladman <riemannic@gmail.com> wrote:
I probably also need to take Counter() more seriously but I have shied away from it until now, fearing that it might be more focussed on 'counting' than on 'multiset operations'
I think you correct about that — Counter can be a way to build a multiset, but not do anything with it. (i.e. such as the API here: https://multiset.readthedocs.io/en/stable/). It seems that’s just what you want. Honestly, despite the idea of “batteries included”, it is very common these days to need a third party lib. If that package meets your needs, then great. If it’s lacking in some way, then suggest (better yet, contribute) improvements. If you still think that package, or something like it, should be in the stdlib, Then you’ll need to make the case that it’s a commonly enough used feature to justify addition to the stdlib. For my part, I don’t think I’ve ever had a need for a multiset - so a third party lib is fine. I have no idea if I’m unusual, but that’s the case you’d need to make. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker wrote:
(i.e. such as the API here: https://multiset.readthedocs.io/en/stable/). It seems that’s just what you want. Honestly, despite the idea of “batteries included”, it is very common these days to need a third party lib. If that package meets your needs, then great. If it’s lacking in some way, then suggest (better yet, contribute) improvements.
Thank you for your thoughts Chris. My main concern is not that I can't find a multiset package that meets my needs, but rather that I have to look for and then integrate the combinatorial algorithms that I need to use with multisets. With 'sets and itertools' I have the type and I have the four main combinatorial algorithms I need readily packaged and very widely used tested in this combination of 'a type with associated algorithms'. But for multisets and combinatorial algorithms I have to do the integration of the type and the algorithms myself and I see this as less than ideal for two reasons. Firstly this combination is tested by me alone and gets none of the benefits of widespread testing that come from a 'community wide integration' such as that which we have with 'sets and itertools'. Secondly although I am fairly confident that I am not completely alone in wanting this combination, there is no obvious way of creating a community that would lead to the emergence of a combined effort to support this 'type/algorithm' integration. Brian
On Sat, Aug 20, 2022 at 10:22 AM Brian Gladman <riemannic@gmail.com> wrote:
My main concern is not that I can't find a multiset package that meets my needs, but rather that I have to look for and then integrate the combinatorial algorithms that I need to use with multisets.
With 'sets and itertools' I have the type and I have the four main combinatorial algorithms I need readily packaged and very widely used tested in this combination of 'a type with associated algorithms'.
But for multisets and combinatorial algorithms I have to do the integration of the type and the algorithms myself and I see this as less than ideal for two reasons.
Firstly this combination is tested by me alone and gets none of the benefits of widespread testing that come from a 'community wide integration' such as that which we have with 'sets and itertools'. Secondly although I am fairly confident that I am not completely alone in wanting this combination, there is no obvious way of creating a community that would lead to the emergence of a combined effort to support this 'type/algorithm' integration.
The stdlib ilib has a very high barrier to entry -- it's one of the hardest way to get this kind of integration. As I said, I haven't had a need to multisets, but I as you say -- what's needed is an integration of a type and a set of algorithms. So I'd suggest that one of two options is available for finding that community: 1) Add algorithms to the multiset package 2) Add a Multiset to more-itertools You might reach out to the maintainers of those two packages to see if they are interested. If not, the third option of course is to build a new package -- as you say, it's hard to get a community around that, but if it is generally useful and you build something good -- maybe people will come. If not, you still have some nice tools to use yourself :-) Good luck, -CHB
Brian _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XIYNOY... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker writes:
It seems that’s just what you want. Honestly, despite the idea of “batteries included”, it is very common these days to need a third party lib.
Just because your Gameboy came with batteries, doesn't mean that your favorite game was included. The idea of "batteries included" is that everything you need to get started on "real work" is included, not that your "real work" is already done for you. It also needs to be one size fits all (does anybody else remember Mad Magazine's sexist "one size fits all" cartoon? -- sometimes it "fits" but it's been stretched beyond all reason!) And its dev cycle needs to fit the stdlib's. A lot of packages of quite general interest will be releasing feature releases quarterly, or even monthly. Of course the lines to draw for all of those desiderata are judgment calls, but the principles are valid. Steve
participants (4)
-
Brian Gladman -
Christopher Barker -
Raymond Hettinger -
Stephen J. Turnbull