[Python-Dev] Add a "transformdict" to collections

[Antoine Pitrou]

On Wed, 11 Sep 2013 19:31:56 +0200
"Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 11.09.13 15:04, schrieb Antoine Pitrou:
> > There are not many possible APIs to create case-insensitive dicts, or
> > identity dicts. 
> 
> That is certainly not true. Most obviously, you have the choice of a
> specialized case-mapping dict, or a generalized type that can be used
> for case mapping also. Does any of the referenced use cases actually
> use the API that you are proposing (i.e. with a key transformation
> function)?

Well, when you have a specialized need, you don't implement a generic
version (*), so I don't think anybody implemented it ;-). The point of a
generic API is to help replace all specialized implementations at once,
rather than a small subset of them.

(*) even the Twisted people don't seem to go that far

> FWIW, I can think of yet another API for this: write a Proxy class
> 
> class TransformedKey: # untested
>   def __init__(self, original):
>     self.original = original
>     self.transformed = self.transform(original)
>   def __hash__(self):
>     return hash(self.transformed)
>   def __eq__(self, other):
>     return self.transformed == other.transformed
>   def transform(self, key):
>      raise NotImplementedError
> 
> If there is then disciplined use in the form
> 
>   d[TransformedKey(key)] == value

The problem is "disciplined use" here. This means any consumer of your
API has to know about that quirk, so it's an inferior solution.

(TransformedKey could be an internal detail of the
implementation, as with weak dictionaries; but as a public API it
doesn't seem very desirable)

> The "transformdict" type
> is not at all "natural", even though it may be useful.

By that token, nothing is "natural" ;-) defaultdict isn't natural, yet
it went in without a PEP.

However, to all persons who already had that need and responded to the
proposal, the generic version *does* seem natural enough, AFAICT. Only
people who've never had such a need seem to fail to "grasp" it (and I
only counted one such person, but my memory may be failing me).

You know, I'm not against having "only" a case-insensitive dict. But
that would be less useful all the while not being significantly easier
to use, so I'm not really seeing the point.

> If you really want to "push" this API into 3.4, I think you will need
> to write a PEP, and find a PEP dictator who is willing to approve it.
> As you seem to dislike the idea of writing a PEP, I suggest to follow
> the idea of publishing it on PyPI now, and then proposing it for
> inclusion into 3.5.

What I dislike is the idea of doing additional work because some
barriers are imposed ;-). PEP or PyPI are on a similar scale here. At
least a PEP would help record the various discussion details, so I'd
favour that over the PyPI path.

Regards

Antoine.