[Python-3000] Nix dict.copy()

[Guido van Rossum]

On Feb 12, 2008 2:20 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>
> > Here's another way to look at it, maybe it'll help. My hunch is that
> > whenever someone writes x = copy(y), they actually know more about the
> > type of y than just that it is an object!
>
> I don't see how this is much different than the situation
> with __iter__. If you know that y is a sequence of items
> of type Y, then you know that iter(y) probably produces
> an object with a next() method that returns objects of
> type Y.
>
> If you're talking about programmers doing type analysis
> in their heads, I think the type system they use is quite
> a sophisticated one, certainly a parametric one that has
> no trouble coping with things like this.

It depends. I used Google Code Search to find examples of copy.copy().
Many were hard to understand because there was no clue about the
argument passed it, and the copy() call doesn't help me infer its type
either. Contrast this with example code using iter() -- it tells me
that the argument is an iterable. That rules out lots of
possibilities, like numbers.

> > I realize I'm doing a lousy job of explaining me.
>
> What's confusing is that you're talking about static
> typing issues in a language that has no static type
> system. I'm having trouble seeing the relevance.

Trust me, there is a relevance to it in my head! It has to do with
Python's ancestry from ABC, which did static type inference.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)