On 8 Oct 2013 18:36, "Antoine Pitrou" <solip...@pitrou.net> wrote: > > Le Tue, 8 Oct 2013 08:21:43 +0200, > Antoine Pitrou <solip...@pitrou.net> a écrit : > > > > > I think there *is* a potentially worthwhile generalisation here, > > > but I'm far from sure "is-a-dict" is the right data model - for > > > composability reasons, it feels like a "has-a" relationship with an > > > underlying data store may make more sense. > > > > It doesn't work. Your "underlying mapping" can show too much variation > > for the wrapper/proxy to have sane semantics. For example, how do you > > combine with a defaultdict or a WeakKeyDictionary, knowing that the > > wrapper/proxy has to have its own internal mapping as well? > > (for the record, I'm saying that because I did try the composition > route.)
It's OK if the key transforming API has to constrain the behaviour of the underlying mapping or require an appropriately designed transform function to handle more esoteric containers. Either would still be better than categorically *disallowing* composition to the point where you can't even compose it with OrderedDict. ChainMap doesn't compose sensibly with arbitrary mappings like defaultdict, but composition is still the right design choice because it works well with *most* custom mappings. It's not that I think this is necessarily a *bad* idea (although the composability problem gives me grave doubts), it's that I think it's not an *urgent* idea, so why rush to review and include it in the weeks remaining before the beta, when the option of publishing it as a recipe or a PyPI module remains available? Enums eventually made it in because we wanted to *use* them to dramatically improve error messages from other stdlib modules. What's the comparable end user payoff for including TransformDict in 3.4 rather than 3.5 (or never)? Cheers, Nick. > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
