Pre-PEP: Dictionary accumulator methods
gsakkis at rutgers.edu
Sun Mar 20 05:04:32 CET 2005
"John Machin" <sjmachin at lexicon.net> wrote in message
news:1111282938.369330.199560 at g14g2000cwa.googlegroups.com...
> George Sakkis wrote:
> > +1 on this. The new suggested operations are meaningful for a subset
> of all valid dicts, so they
> > should not be part of the base dict API. If any version of this is
> approved, it will clearly be an
> > application of the "practicality beats purity" zen rule, and the
> justification for applying it in
> > this case instead of subclassing should better be pretty strong; so
> far I'm not convinced though.
> My background: I've been subclassing dict since this was possible, to
> provide not only a count/tally method but also a DIY intern method.
> Before that I just copied dictmodule.c (every release!) and diffed and
> hacked about till I had a mydict module.
> *any* version? Could we make you happy by having a subclass
> TotallySinfulDict provided as part of the core? You don't have to use
> it -- come to think of it, you don't have to use a sinful method in the
> base dict. You could even avert your gaze when reading the
> The justification for having it in the core: it's in C, not in Python,
> it gets implemented and maintained (a) ONCE (b) by folk like the timbot
> and Raymond instead of having (a) numerous versions lashed up (b) by
> you and me and a whole bunch of n00bz and b1ffz :-)
I believe it was pretty clear that I'm not against a new dict extension, in the core or in the
standard library; the proposed functionality is certainly useful and it would be most welcome. I
just don't find it appropriate for the existing base dict because it is not applicable to *every*
dictionary. As for the "you don't have to use feature X if you don't like it" argument, it's rarely
relevant in language design.
More information about the Python-list