Rejection

See the rationale athttps://mail.python.org/pipermail/python-dev/2015-May/140003.htmland for an earlier partial review, seehttps://mail.python.org/pipermail/python-dev/2013-October/129937.html .

Constructor

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

The constructor also takes other optional arguments which can be usedto initialize the TransformDict with certain key-value pairs. Thoseoptional arguments are the same as in thedict anddefaultdictconstructors:

>>>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 keytogether 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>", line1, in<module>KeyError:'bar'

The method namegetitem() follows the standardpopitem() methodon mutable mappings.

Getting the transformation function

TransformDict has a simple read-only propertytransform_func whichgives back the transformation function.

Retaining the last original key

Most python-dev respondents found retaining the first user-supplied keymore intuitive than retaining the last. Also, it matches the dictobject’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-retainingscheme 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-retainingscheme) doesn’t look possible without rewriting part of the container’scode.

Using an encoder / decoder pair

Using a function pair isn’t necessary, since the original key is retainedby the container. Moreover, an encoder / decoder pair would require thetransformation to be bijective, which prevents important use caseslike case-insensitive matching.

Providing a transformation function for values

Dictionary values are not used for lookup, their semantics are totallyirrelevant to the container’s operation. Therefore, there is no point inhaving both an “original” and a “transformed” value: the transformedvalue wouldn’t be used for anything.

Providing a specialized container, not generic

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

Even case-insensitive dicts can actually elicit different transformationfunctions:str.lower,str.casefold or in some casesbytes.lowerwhen working with text encoded in an 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:

  classCaseInsensitiveDict(TransformDict):__transform__=str.casefoldd=CaseInsensitiveDict(Foo=1)

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

Other languages