On Wed, 11 Sep 2013 19:31:56 +0200 "Martin v. Löwis" firstname.lastname@example.org 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.