On Sat, Apr 2, 2022 at 6:30 AM Steve Dower <steve.do...@python.org> wrote:
> >> + 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. > Sure -- as i understand it, there is increasing effort to define the various levels and stabilities of the C API -- it doesn't seem an intractable problem to define a new type as having an unstable API for a period of time. And as HAMT is there, it's gotten at least a little use. And if we want to hammer out the details, giving it wider use would be a way to do that. > Yes, and the request in this thread was "expose the HAMT", not "create a > new data type that uses it under the covers". > OK, sure, but we were also pointed to PEP 603 -- which seems to have stalled. I'm supportive of the general idea -- even if a few details need to be resolved. 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(). That's the challenge of naming anything ;-) For my part, yes, I'd rather an immutable Mapping that is as much like dict as possible. I just went and read the whole thread in discuss, and this one quote reflects my take as well: """ I’m not sure whether the specific implementation and API of this frozenmap is a good one, but some kind of immutable, hashable mapping seems to be commonly requested and commonly re-invented. """ Then there's Raymond's point: "But the PEP is about something different – it is algorithm focused." So yes, I get what the issue is now. Then there is the end of the thread: "I think the hold-up is Yury having time to continue pushing the PEP forward." So it's stalled out, rather than being rejected due to any intractable issues. For my part: I think there is substantial demand for an immutable Mapping type. And having it in the stdlib would be a real benefit -- as it happens, last week I wanted it not for my own code, but for a little prototype of a "anonymous names tuple" as discussed on python-ideas -- no idea if that is going anywhere, but there have got to be multiple potential uses in the stdlib. Another thing to keep in mind is that for most uses, the exact performance characteristics really don't matter much. For me, that points to an implementation that mimics the dict API (i.e. preserves order). If someone needs an implementation that has specific performance characteristics that are different, and doesn't need key order preservation, then THAT can be a special case. Which, IIUC, is what the current HAMT in cPython is about. Anyway, it would be nice for someone to take up the mantle of getting an immutable Mapping into the stdlib. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/E7CJWMGW7WK7J5B4ZMS3HJBONS3RW5FO/ Code of Conduct: http://python.org/psf/codeofconduct/
