Should'nt the key'ing behaviour be controlled by the type of the key instead of the type of the container?
2013/9/10 MRAB <pyt...@mrabarnett.plus.com> > On 10/09/2013 20:08, Paul Moore wrote: > >> On 10 September 2013 19:31, Antoine Pitrou <solip...@pitrou.net> wrote: >> >>> I think it would be a flaw to have this detail implementation-defined. >>>> This would be like saying that it is implementation-defined which >>>> of A,B,C is returned from "A and B and C" if all are true. >>>> >>> >>> Ok, it seems everyone (except me :-)) agrees that it should return the >>> first key value, so that's how it will be. >>> >> >> If you retain the first key value, it's easy enough for the >> application to implement "retain the last" semantics: >> >> try: >> del d[k] >> finally: >> d[k] = v >> >> That would raise a KeyError is the key was missing. A better way is: > > d.pop(k, None) > > d[k] = v > > If you provide "retain the last", I can't see any obvious way of >> implementing "retain the first" in application code without in effect >> reimplementing the class. >> >> "Retain the first" does feel more natural to me. > > ______________________________**_________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/**mailman/listinfo/python-dev<https://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: https://mail.python.org/**mailman/options/python-dev/** > lukas.lueg%40gmail.com<https://mail.python.org/mailman/options/python-dev/lukas.lueg%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