It strikes me that there could be an alternative approach to some of the use cases discussed here. Instead of a new type of dictionary, the case-insensitivity problem could be solved with something akin to a * CaseInsensitiveString* class used for keys within a standard dictionary. This would be very similar to a normal string except with comparison and hashing. It would mean that CaseInsensitiveString("Foo") is considered equal to CaseInsensitiveString("foo") and allow code such as the following: >>> headers = {} >>> headers[CaseInsensitiveString("content-type")] = "text/plain" >>> headers[CaseInsensitiveString("Content-Type")] "text/plain" This would obviously also be usable in other places where case-insensitive strings are required. Just my two pence/cents/other minor currency units. Nigel On 30 October 2013 14:18, Ethan Furman <ethan at stoneleaf.us> wrote: > On 10/30/2013 12:12 AM, Raymond Hettinger wrote: > >> >> Hopefully, this post will make the thought process more transparent. >> > > Thanks, Raymond. Your time is appreciated. > > -- > ~Ethan~ > > ______________________________**_________________ > Python-Dev mailing list > Python-Dev at 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/** > nigel%40nigelsmall.com<https://mail.python.org/mailman/options/python-dev/nigel%40nigelsmall.com> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131030/9a34d8fe/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4