<p dir="ltr"><br>
On 8 Oct 2013 22:31, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> Le Tue, 8 Oct 2013 22:12:02 +1000,<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> a écrit :<br>
> ><br>
> > It's OK if the key transforming API has to constrain the behaviour of<br>
> > the underlying mapping or require an appropriately designed transform<br>
> > function to handle more esoteric containers. Either would still be<br>
> > better than categorically *disallowing* composition to the point<br>
> > where you can't even compose it with OrderedDict.<br>
><br>
> Well, you could ask the same question about OrderedDict, defaultdict or<br>
> Weak*Dictionary since neither of them use composition :-)</p>
<p dir="ltr">We *did* ask the same question about those (except the Weak* variants, simply due to age).</p>
<p dir="ltr">Each time, the point that each new dict variant would be used to justify yet *more* variants was a cause for concern.</p>
<p dir="ltr">defaultdict made it through because it's just a convenience API for the underlying "key missing" protocol, while OrderedDict spent time maturing outside the standard library first.</p>
<p dir="ltr">><br>
> > ChainMap doesn't<br>
> > compose sensibly with arbitrary mappings like defaultdict, but<br>
> > composition is still the right design choice because it works well<br>
> > with *most* custom mappings.<br>
><br>
> ChainMap is easy to compose since it doesn't have to keep any<br>
> data-driven internal state.</p>
<p dir="ltr">Yet composing ChainMap with defaultdict still breaks, because it's a conceptually incoherent thing to do.</p>
<p dir="ltr">"Composition doesn't work with some mappings" isn't an adequate answer to the criticism that a composition based design could work with more mappings than just the builtin dict.</p>
<p dir="ltr">> > It's not that I think this is necessarily a *bad* idea (although the<br>
> > composability problem gives me grave doubts), it's that I think it's<br>
> > not an *urgent* idea, so why rush to review and include it in the<br>
> > weeks remaining before the beta, when the option of publishing it as<br>
> > a recipe or a PyPI module remains available?<br>
><br>
> It's just that I disagree we're rushing anything. The feature is fairly<br>
> simple, many people have already had a need for something like that.<br>
> (and amongst those people absolutely *zero* have said the design of the<br>
> feature proposal is inadequate)</p>
<p dir="ltr">Except the one who wanted to combine it with OrderedDict. Users won't be able to combine it with ChainMap either.</p>
<p dir="ltr">The concrete container vs container-wrapper design decision is a fundamental one and I don't believe the current PEP adequately makes the case in favour of the former.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>