On 02Apr2022 0925, Paul Moore wrote:
On Sat, 2 Apr 2022 at 02:30, Christopher Barker <python...@gmail.com> wrote:
On Fri, Apr 1, 2022 at 4:06 AM Steve Dower <steve.do...@python.org> wrote:
The main difference is that 'immutables' offers you a stable/versioned
interface to use it, while the one that's in CPython is an internal
implementation detail. If one day we find a better design, we can just
switch to it, while 'immutables' probably can't. If we've exposed as a
public interface in the core runtime, it's much more complicated.
I don't understand the issue here:
If we expose a "frozendict" as built in python object then only the API of that
object needs to remain stable, not the implementation.
And it seems that's an API that is already clearly defined.
+ 1 from me -- just the other day I was wishing it was there.
There would presumably need to be be a C API as well, and that would
probably expose more of the implementation unless handled carefully.
Without seeing an actual implementation, it's hard to know for sure.
Yes, and the request in this thread was "expose the HAMT", not "create a
new data type that uses it under the covers".
My opposition to the new data type was that it *wasn't* frozendict,
primarily because we decided that dicts had to preserve insertion order.
So it was proposed as "frozenmap", but was more like a dict than map().
It's also slightly slower for lookups (as well as technically not O(1),
though close enough for moderate N), and the primary benefit is reduced
memory usage when you mutate it (but it's frozen...? ;) ).
All of that kind of adds up to make it a distraction that's likely worse
than a dict subclass with __setitem__ overridden (if that's the
behaviour you want). It's a fantastic data structure for when you need
it, but it's one that deserves to be researched and understood before
simply dropping it into your code. An optional package is a perfectly
good place for it.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/VFSXMPGG7Q3YOAZKKNHLLW5TPHJPU3OS/
Code of Conduct: http://python.org/psf/codeofconduct/
