Modifying the {} and [] tokens

[Geoff Howland]

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

>
>"Geoff Howland" <ghowland at lupineNO.SPAMgames.com> wrote in message
>news:km4fkv8qbbge3mvckv5gsim9amq59qvohb at 4ax.com...
>> 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.

{}.keys().intersect({}.keys)

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
http://ludumdare.com/