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/
