Modifying the {} and [] tokens

Geoff Howland ghowland at
Sat Aug 23 20:09:28 CEST 2003

On Sat, 23 Aug 2003 13:39:15 -0400, "Terry Reedy" <tjreedy at>

>"Geoff Howland" <ghowland at> wrote in message
>news:km4fkv8qbbge3mvckv5gsim9amq59qvohb at
>> For the [].len() type things, this is obviously a matter of taste
>There is also history (and backwards compatibility).  Once upon a
>time, neither strings nor tuples had methods, so neither 'abc'.len()
>nor (1,2,3).len() would have been possible.

Thanks for the info.  Always good to know history, and sometimes hard
to find with the glut of common information repeated on the net
(finding the same function definition pages over and over while
looking for something the first one you found didn't have  :) ).

>With respect to {}+{}.  An in-place version of this is currently
>spelled {}.update({}).  Yes, more chars to type, but also more
>'honest' in not implying symmetry between the two dicts.  As the name
>suggests, duplicate key with new value overrides previous value.

What's really the problem with a + sugar though?  Currently there is
no sugar, and update() really all there is to it.

This is a little more pronounced when doing slightly more complex
things like finding the intersection to things.  I wouldn't be opposed
to less operators, but at least having the functions.


Something like that, and the reverse.  I belevie there is a PEP for
sets around, maybe that will fix this problem.  Unless it doesn't mesh
with any of these other containers well.

-Geoff Howland

More information about the Python-list mailing list