> > As far as I can see, the only downside of this is that it would means a > new standard dunder, which is a substantial downside, as (I think) it > essentially adds overhead in all sorts of places, plus ads "One more > protocol" to a language already ripe with protocols. >
I like the __as_mapping__ idea a lot since it leaves it up to the user to determine how dict() does dict-making. But I understand how the overhead from adding a single function call could be very significant to something that is used as often as dict(). What about pairing a __mapping__ method with a mapping() function instead? mapping() would not need to be a keyword; it might make sense as part of, perhaps, the types library. types.mapping() would be significantly slower than dict() only sometimes-- and resource critical code could still rely on dict(). But it would also be more forgiving. And possibly even more useful (for the reasons I've tried to do a good job of outlining).
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
