[Python-Dev] PEP 455: TransformDict

[Nick Coghlan]

On 8 Oct 2013 07:26, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
>
> > (If we cannot find a better name, we may add more specialized classes:
> > KeyInsensitiveDict and IdentiyDict. But I like the idea of using my
> > own "transform" function.)
>
> -1 on a plethora of specialised dicts.
>
> I do think that a TransformDict seems useful, and might even *be*
> useful, but would not like to see a whole pile of specialised dicts
> added to the std lib.
>
> I wonder though, are we going about this the wrong way? Since there is
> apparently disagreement about TransformDict, that suggests that perhaps
> we need more concrete experience with the basic idea before graduating
> to a concrete class in the std lib. Perhaps we should follow the example
> of dict, __missing__ and defaultdict. The dict class could do something
> like this on key access:
>
> if type(self) is not dict:
>     # This only applies to subclasses, not dict itself.
>     try:
>         transform = type(self).__transform__
>     except AttributeError:
>         pass
>     else:
>         key = transform(key)
> # now use the key as usual
>
>
> Am I barking up the wrong tree? Would this slow down dict access too
> much?

The problem is doing this in a way that keeps a strong reference to the
original key (and produces that when iterating) while doing the lookup
based on the transformed keys.

That said, with the current plan to lower the barrier to entry for PyPI
dependencies (I should have the 3.4 only ensurepip proposal written up some
time this week), I think it makes sense to let this one bake on PyPI for a
while.

I think there *is* a potentially worthwhile generalisation here, but I'm
far from sure "is-a-dict" is the right data model - for composability
reasons, it feels like a "has-a" relationship with an underlying data store
may make more sense. (If performance is critical, you're going to write a
dedicated type anyway, so composability and simplicity strike me as more
important criteria at this point).

Cheers,
Nick.

>
>
> --
> Steven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131008/956d9cd2/attachment.html>