Please bring your questions to https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/... to have the single discussion site.
On Fri, Sep 13, 2019 at 5:06 AM Andrew Barnert abarnert@yahoo.com wrote:
On Sep 12, 2019, at 11:15, Andrew Svetlov andrew.svetlov@gmail.com wrote:
As Yuri said the proposed implementation is 15x times faster than pyrsistent. hamt library doesn't exist on PyPI.
I probably didn’t remember the names of all of the relevant PyPI projects off the top of my head. But shouldn’t that be included in the PEP so people don’t have to remember and/or search?
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).
OK, the fact that immutables uses the same C data structure implementation that’s already in Python surely outweighs the fact that it’s not a category-killer.
(i assume that either there’s a pure-Python version for PyPy and other implementations, or that those implementations are expected to already include some code that’s equivalent to what hamt.c does that can be accessed the same way?)
But that doesn’t answer any of the questions about the API design. Shouldn’t the PEP explain why various features were included, or left out, or designed differently than in existing third-party libraries (and equivalent features in other languages)? Just “one of the existing libs made these choices for reasons that aren’t documented anywhere” doesn’t seem like enough of a rationale.
Again, I don’t think there’s anything wrong with the decisions. (For example, evolve, or whatever he calls it, is useful more often than zippers, and harder to build yourself on top of a library that doesn’t provide it; etc.) Just that the PEP should make the case for each such decision.