>> I don't think we'll ever get another chance to clean-up the mapping API and 
>> to remove duplicate functionality (the code for
>> dict.__copy__ and dict.copy share the same implementation).
> 
> I find the use of a copy operation that purports to copy any object
> suspect (regardless whether it's a module or a builtin), and that I'd
> rather have a copy() method on the MutableMapping API.

Should I revert the -3 warning on copy() methods that I checked-in a few days 
ago?



> I think my objection against the fully generic copy operation is that
> it's type is useless -- all we know that it is supposed to return the
> same type as its argument, but our type system can't express that.

I'm not sure I follow you here.  The definition of Iterator.__iter__
is to return self, so it doesn't seem like much of a leap to express 
a signature with a return type of type(self).

Or, were you saying that the actual problem is that we can't know
in advnace the signature of  type(self).__init__()?

> The
> type of the more constrained (but still generic in the sense of PEP
> 3124) copy operation on mutable sequences is better defined -- it
> returns another mutable sequence, with the understanding that it
> typically returns something of the same type as its input, though not
> always -- e.g. if I subclass dict but don't override .copy(), the
> inherited .copy() method returns a dict, not my subclass.

The part I'm not following in this paragraph is how a d.copy()
method is any different from the d.__copy__() method that
is called by the copy() function.  Both share the same underlying
implementation and both have the same effects when overridden.

If all we want a guaranteed dict, why not write dict(obj)?  
This already works with all the dict lookalikes because they
define obj.keys() and obj.__getitem__().


Raymond
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to