On 13 September 2013 01:40, Antoine Pitrou <solip...@pitrou.net> wrote:
> Le Thu, 12 Sep 2013 08:05:44 -0700,
> Ethan Furman <et...@stoneleaf.us> a écrit :
> > On 09/12/2013 07:43 AM, Antoine Pitrou wrote:
> > >
> > > Yeah, so this is totally silly. What you're basically saying is "we
> > > don't need TransformDict since people can re-implement it
> > > themselves".
> >
> > No, what I'm saying is that the "case-preserving" aspect of
> > transformdict is silly. The main point of transformdict is to
> > enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the
> > same key. But why? Because you don't trust the user data. And if
> > you don't trust the user data you have to add the correct version of
> > the key yourself before you ever process that data, which means you
> > already have the correct version stored somewhere.
>
> That's assuming there is an a priori "correct" version. But there might
> not be any. Keeping the original key is important for different reasons
> depending on the use case:
>
> - for case-insensitive dicts, you want to keep the original key for
> presentation, logging and debugging purposes (*)
>
> - for identity dicts, the original key is mandatory because the id()
> value in itself is completely useless, it's just used for matching
>
> (*) For a well-known example of such behaviour, think about Windows
> filesystems.
>
In this case though, there are two pieces of information:
1. A canonical key (which may or may not equal the original key);
2. The original key.
It seems to me then that TransformDict is a specialised case of
CanonicalDict, where the canonical key is defined to be the first key
inserted. It would in fact be possible (though inefficient) to implement
that using a canonicalising callable that maintained state - something like
(untested):
class OriginalKeys:
def __init__(self)::
self.keys = CanonicalDict(str.lower)
def __call__(self, key):
return self.keys.setdefault(key, key)
class OriginalKeyDict(CanonicalDict):
def __init__(self)::
super().__init__(OriginalKeys())
Tim Delaney
_______________________________________________
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
