Rejection

See the rationale at https://mail.python.org/pipermail/python-dev/2015-May/140003.html and for an earlier partial review, see https://mail.python.org/pipermail/python-dev/2013-October/129937.html .

Constructor

As shown in the examples above, creating a TransformDict requires passing the key transformation function as the first argument (much like creating a defaultdict requires passing the factory function as first argument).

The constructor also takes other optional arguments which can be used to initialize the TransformDict with certain key-value pairs. Those optional arguments are the same as in the dict and defaultdict constructors:

>>> d = TransformDict(str.casefold, [('Foo', 1)], Bar=2)
>>> sorted(d.items())
[('Bar', 2), ('Foo', 1)]

Getting the original key

TransformDict also features a lookup method returning the stored key together with the corresponding value:

>>> d = TransformDict(str.casefold, {'Foo': 1})
>>> d.getitem('FOO')
('Foo', 1)
>>> d.getitem('bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'bar'

The method name getitem() follows the standard popitem() method on mutable mappings.

Getting the transformation function

TransformDict has a simple read-only property transform_func which gives back the transformation function.

Retaining the last original key

Most python-dev respondents found retaining the first user-supplied key more intuitive than retaining the last. Also, it matches the dict object's own behaviour when using different but equal keys:

>>> d = {}
>>> d[1] = 'hello'
>>> d[1.0] = 'world'
>>> d
{1: 'world'}

Furthermore, explicitly retaining the last key in a first-key-retaining scheme is still possible using the following approach:

d.pop(key, None)
d[key] = value

while the converse (retaining the first key in a last-key-retaining scheme) doesn't look possible without rewriting part of the container's code.

Using an encoder / decoder pair

Using a function pair isn't necessary, since the original key is retained by the container. Moreover, an encoder / decoder pair would require the transformation to be bijective, which prevents important use cases like case-insensitive matching.

Providing a transformation function for values

Dictionary values are not used for lookup, their semantics are totally irrelevant to the container's operation. Therefore, there is no point in having both an "original" and a "transformed" value: the transformed value wouldn't be used for anything.

Providing a specialized container, not generic

It was asked why we would provide the generic TransformDict construct rather than a specialized case-insensitive dict variant. The answer is that it's nearly as cheap (code-wise and performance-wise) to provide the generic construct, and it can fill more use cases.

Even case-insensitive dicts can actually elicit different transformation functions: str.lower, str.casefold or in some cases bytes.lower when working with text encoded in a ASCII-compatible encoding.

Other constructor patterns

Two other constructor patterns were proposed by Serhiy Storchaka:

• A type factory scheme:

  d = TransformDict(str.casefold)(Foo=1)
  

• A subclassing scheme:

  class CaseInsensitiveDict(TransformDict):
      __transform__ = str.casefold
  
  d = CaseInsensitiveDict(Foo=1)
  

While both approaches can be defended, they don't follow established practices in the standard library, and therefore were rejected.

Other languages