Good evening, On Fri, 4 Oct 2013 13:38:05 -0700 Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > > You can also add to the discussion by trying out your own usability > tests on people who haven't been exposed to this thread or the pep.
I think "usability tests" should be conducted on people who actually have a need for the API. Otherwise they simply don't make sense: if you don't need an API, then you don't have to learn / understand it either. As an example, if you conduct random usability tests about "yield from" (PEP 380, accepted) or single-dispatch generic functions (PEP 443, accepted), you'll probably get a negative outcome, especially on students. Or if you conduct usability tests about the ssl module on someone who's never done any network programming, you'll get the similar kind of negative results. > * When given a description of the mechanics of a TransformDict, > they don't seem to be able to figure-out what you would do with it > without being given an example. Well, the documentation is the place where we give examples. > * When given a example of using a TransformDict, they understand > the example but don't seem to be able to come-up with other examples > other than the one they were just shown. Is it any different for e.g. defaultdict? Because the mechanics are exactly the same: a generic construct which you can specialize for various use cases. > * This contrasts with the results when I show something less general > like a CaseInsensitiveDict. People seem to get that right away. > As you might expect, the generalized solution is harder to wrap > your head around than a specific solution with a clear name. Yet the generic solution is applicable to far many cases than the specialized one. I'm not against adding a CaseInsensitiveDict, but that would be a rather bizarre thing to do given we can add a generic construct that's far more powerful, and not significantly more difficult. > * One student asked, "why give regular dicts a key-function like > sorted(), min() and max()?" I didn't have a good answer, but I > haven't yet had time to read this whole thread. :-) The key answer is: when you want to retain the original key. > * Another issue is that we're accumulating too many dictionary > variants and that is making it difficult to differentiate and choose > between them. It shouldn't be difficult, actually, because it doesn't make sense to "choose" at all. The use cases for OrderedDict, Counter, TransformDict and defaultdict are completely different. > I haven't found anyone (even in advanced classes > with very experienced pythonistas) would knew about > all the variations: dict, defaultdict, Mapping, MutableMapping, > mapping views, OrderedDict, Counter, ChainMap, andTransformDict. Is that actually a problem? > Overall, my impression at this point is that key transformations > are useful, but I'm not sure how to incorporate them without > taking Python further away from being a language "that just fits > in your head." The language fits in your head, but the stdlib doesn't. I don't think it has done so for ages :-) I'm not proposing TransformDict as a builtin, though. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
