As Yuri said the proposed implementation is 15x times faster than pyrsistent. hamt library doesn't exist on PyPI. immutables library is a code written by Yuri, it uses hamt datastructure internally. Basically, the proposed frozenmap is a port of immutables (with the class renaming). In turn, immutables is a CPython hamt.c with python wrappers.
On Thu, Sep 12, 2019 at 6:55 PM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote: > > On Sep 12, 2019, at 04:46, Yury Selivanov <yselivanov...@gmail.com> wrote: > > > > Hi! > > > > I've just published a PEP to add a frozenmap type to Python; it should > > be online shortly. > > > > Read it here: > > https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318 > > How does this compare in performance, features, API, etc. to pyrsistent, > immutables, hamt, and other third-party implementations on PyPI? > > Not all of the features provided by all of the third-party libs are necessary > (Haskell-style zippers; items and friends that return a lazy list instead of > an iterator; instar-style transforms), but it would be nice to know that they > were considered and rejected, and why. > > And, similarly, it would be nice to have a rationale for why we _do_ need the > evolve (or whatever it’s called—the temporarily mutable copy via chain thing) > thing, and if/ how/why it differs from the other implementations. > > And for features that are included, it would be nice to know how easy it is > to translate to and from the other implementations, and if it’s not just a > trivial respelling (changing setting to including, emacs can take care of for > me; if evolving and locking is a whole different flow, it can’t), why it > can’t be. After all, it’s sometimes been handy that you can pretty quickly > migrate code from, e.g., ipaddress or simplejson or the old OrderedDict > recipe when you can use a newer Python, or the other way when you learn that > you need to deploy on an older Python. If the same is doable for persistent > mappings, that would be a nice-to-have feature (but not if it would require > making the API worse or making everything slower or more complicated). > > Finally, it’s probably not worth adding HAMT-backed sets, lists, etc., just > because we can, even though I think most libraries both in Python and in > other languages do. But it might be worth adding a rationale for _why_ they > aren’t necessary (and mentioning that if we see a lot of people using > frozenmaps with None values as sets in place of frozenset, we can always > easily add something later). > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/2CIPO3OR7JH53KUCCUTWP74JC5N4NRU7/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Thanks, Andrew Svetlov _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/PNGRGDGAL6YGCKRQFFY55SUJ34FGWGEL/ Code of Conduct: http://python.org/psf/codeofconduct/
