[Python-3000] Nix dict.copy()

[VanL]

Daniel Stutzbach wrote:
> Okay, but turn it around for a minute.  Which types should have a 
> .copy() method and why?

I would argue that it's not about mappings, it's about mutability. I 
always thought the .copy method on dicts was to allow functions to work 
on a passed-in dict without causing spooky action at a distance due to 
mutability issues. (See the silly example at the end of the post.) Sets, 
being by default mutable, got the same treatment.

Other types (other than lists) aren't susceptible to this sort of 
problem. The default idiom for lists,  copy = list[:], is a workaround 
for the lack of a .copy() method.

I would argue that if you want to make some sort of ABC, make it a 
'Mutable' ABC and put the .copy method in *there*. \

- Van

*For example, you can get into this problem when using dicts for string 
substitution:

def fragment1(vars, boilerplate=''):
    if boilerplate: vars['extra'] = boilerplate
    return "%(sentence)s with %(something)s %(extra)s." % vars

def fragment2(vars, boilerplate=''):
    if boilerplate: vars['extra'] = boilerplate
    return "%(another)s %(sentence)s with %(extra)s." % vars

def statement():
    # vars is a dict built from a database query
    vars = get_dict_from_db()
    return '%s %s' % (fragment1(vars, 'extra'), fragment2(vars))

Because of mutability, the 'extra' in fragment1 will also show up in 
fragment2. The solution to this is to make a .copy(). The susceptibility 
of newbies to this 'spooky action at a distance' problem is one of the 
reasons why mutability and immutability have to be addressed almost at 
the very start of many learning Python books.