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
On Feb 12, 2008 3:11 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 4:52 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> >
> > > What useful information do we get by knowing that a type has a .copy()
> > > method?
> >
> > It rules out all classes that don't have one. That's n
On Feb 12, 2008 4:52 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > What useful information do we get by knowing that a type has a .copy()
> > method?
>
> It rules out all classes that don't have one. That's nearly all types.
>
Okay, but turn it around for a minute. Which types should have
On Feb 12, 2008 2:40 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> > Based on the same reasoning, when
we see x = copy(y) we can tentatively
> assume that y is a type that can usefully be copied. Unless we don't trust
> the author of the code to be sensible.
My point is that (almost) any type is copya
Guido van Rossum wrote:
> 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
> th
On Feb 12, 2008 11:56 AM, Guido van Rossum <[EMAIL PROTECTED]> 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! Because if they knew
> *nothing* about i
On Feb 12, 2008 2:20 PM, Greg Ewing <[EMAIL PROTECTED]> 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 se
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
Raymond Hettinger wrote:
> 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.
Having it a fun
On Feb 11, 2008 10:20 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> 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
>> 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
On Feb 11, 2008 7:58 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Where did we end-up on dict.copy()?
>
> Is the copy(obj) function sufficiently universal to replace the obj.copy()
> method used in sets and in dict imitators? Or does the
> need for import preclude it from consideration?
>
>
Where did we end-up on dict.copy()?
Is the copy(obj) function sufficiently universal to replace the obj.copy()
method used in sets and in dict imitators? Or does the
need for import preclude it from consideration?
To me it seems that relationship between __copy__ and the copy() function is
ju
At 05:23 PM 2/11/2008 +1300, Greg Ewing wrote:
>Aahz wrote:
> > On Mon, Feb 11, 2008, Greg Ewing wrote:
> >
> >>There are bound to be things that you *don't* want to copy from
> >>the original order, e.g. the order ID, the date...
> >
> > Certainly -- that's why __copy__() exists, right?
>
>Yes, bu
Greg Ewing wrote:
Yes, but then I don't see the advantage over just giving the object a copy()
method and calling it directly.
In other words, I see little benefit in having copy() be a generic function.
So true! Other candidates for not being generic functions: len(),
repr(), str(), int
Aahz wrote:
> On Mon, Feb 11, 2008, Greg Ewing wrote:
>
>>There are bound to be things that you *don't* want to copy from
>>the original order, e.g. the order ID, the date...
>
> Certainly -- that's why __copy__() exists, right?
Yes, but then I don't see the advantage over just
giving the object
On Mon, Feb 11, 2008, Greg Ewing wrote:
> Aahz wrote:
>>
>> Let's suppose you have an object that represents an order. And let's
>> suppose that this object needs to be copied to create a re-order (letting
>> the customer preserve the information from the original order).
>
> In that case, I wou
On Feb 10, 2008 8:02 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> However, since existing code has to be migrated, and lots of things
> have copy() methods, and 2to3 isn't going to be able to tell,
> practicality (IMO) seems to favor keeping the existing method.
>
If it only converts dict and
Christian Heimes wrote:
Larry Hastings wrote:
+1 for exactly the reasons cited. I think copy() and deepcopy() should
both be "essential" built-in functions.
I'm -0 on copy and -1 on deepcopy.
If you need a copy or a deepcopy of an object (except dicts, lists and
sets) you are most ce
At 11:46 PM 2/10/2008 +, Paul Moore wrote:
>If I want a copy of an arbitrary mapping (or any object) and I want to
>preserve type, I would use copy.copy(). This is just as polymorphic as
>a copy method (interesting that it is Phillip arguing for methods
>being the polymorphic choice, when copy.
Aahz wrote:
> Let's suppose you have an object that represents an order. And let's
> suppose that this object needs to be copied to create a re-order (letting
> the customer preserve the information from the original order).
In that case, I would give my Order class a copy() method (or
re_order(
Paul Moore wrote:
> Given the above, I see no case where I'd want to use dict.copy(). So
> I'm in favour of removing it.
Personally I don't think I would even notice if the entire
contents of the copy module disappeared. I've never used
either form of generic copying. In the rare cases when I
do
On Feb 10, 2008 3:46 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On the other hand, I'd imagine it would be difficult to write a good
> fixer for this. I'm not sure how much of a showstopper that might be.
Cant you just flag it as depreciated and have it actually call
copy.copy() when it is run. T
On Sun, Feb 10, 2008, Christian Heimes wrote:
> Larry Hastings wrote:
>>
>> +1 for exactly the reasons cited. I think copy() and deepcopy() should
>> both be "essential" built-in functions.
>
> I'm -0 on copy and -1 on deepcopy.
>
> If you need a copy or a deepcopy of an object (except dicts, li
On 10/02/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Now, we have one and only one chance to slim-down the mapping API, leaving
> the copy()
> function as the one, universal, preferred way to do it. I don't think this
> chance will come
> again.
This discussion confused me (largely bec
[Martin]
> So indeed, your claim that .copy "is [not]
> really polymorphic" is quite puzzling - we now seem to agree that it
> *is* polymorphic.
Yes, of course. Every method used by dict imitators could be considered
polymophic. I was just observing copy.copy(obj) applies to
many, many more ob
I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d)
is...
>
> [Raymond]
>>> Can't say dict.copy() is really polymorphic if only one other class
>>> defines the method.
>
> [Martin]
>> Why do you say it's only one? I found atleast UserDict.copy,
>> os._Environ.copy, W
On Feb 10, 2008 1:49 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Larry Hastings wrote:
> > +1 for exactly the reasons cited. I think copy() and deepcopy() should
> > both be "essential" built-in functions.
>
> I'm -0 on copy and -1 on deepcopy.
>
> If you need a copy or a deepcopy of an obje
>> [Phillip Eby]
>>> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
[Raymond]
>> Can't say dict.copy() is really polymorphic if only one other class defines
>> the method.
[Martin]
> Why do you say it's only one? I found atleast UserDict.copy,
> os._Environ.copy, Wea
Raymond Hettinger wrote:
> [Phillip Eby]
>> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
>
> Can't say dict.copy() is really polymorphic if only one other class defines
> the method.
Why do you say it's only one? I found atleast UserDict.copy,
os._Environ.copy, Wea
Larry Hastings wrote:
> +1 for exactly the reasons cited. I think copy() and deepcopy() should
> both be "essential" built-in functions.
I'm -0 on copy and -1 on deepcopy.
If you need a copy or a deepcopy of an object (except dicts, lists and
sets) you are most certainly using the wrong approach
Steven Bethard wrote:
Maybe copy.copy() could become __builtin__.copy()?
+1 for exactly the reasons cited. I think copy() and deepcopy() should
both be "essential" built-in functions.
/larry/
___
Python-3000 mailing list
Python-3000@python.org
http
[Phillip Eby]
> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
Can't say dict.copy() is really polymorphic if only one other class defines the
method.
The __copy__ method is more common. The only wrinkle is that the copy()
function isn't a builtin.
Raymond
___
Steven> Maybe copy.copy() could become __builtin__.copy()?
And what of copy.depcopy()? Doesn't seem to be much else public defined in
the copy module:
% python -c 'import copy ; print copy.__all__'
['Error', 'copy', 'deepcopy']
If copy.copy() migrates to builtin it should raise s
On Feb 10, 2008 9:22 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Feb 9, 2008 8:58 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote:
> > >I recommend dropping the dict.copy() method from Py3.0.
> > >
> > >* We can already write: newd = c
On Feb 10, 2008 7:54 AM, Chris Monson <[EMAIL PROTECTED]> wrote:
> Speaking of polymorphic, it seems like it would make sense to allow
> classes to specify their own __copy__ method for cases where
> specialized handling of copy is needed. copy.copy is sometimes
> overzealous, and therefore less e
On Feb 9, 2008 8:58 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote:
> >I recommend dropping the dict.copy() method from Py3.0.
> >
> >* We can already write: newd = copy.copy(d).
> >* We can also write: newd = dict(d)
> >* Both of those appr
- Original message -
I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
Speaking of polymorphic, it seems like it would make sense to allow
classes to specify their own __copy__ method for cases where
specialized handling of copy is needed. copy.copy is sometimes
overzealo
At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote:
>I recommend dropping the dict.copy() method from Py3.0.
>
>* We can already write: newd = copy.copy(d).
>* We can also write: newd = dict(d)
>* Both of those approaches also work for most other containers.
I'm not fond of this idea. dict.
On Feb 9, 2008 5:52 PM, James Y Knight <[EMAIL PROTECTED]> wrote:
> Has anyone thought of making a execution-informed converter? If you
> have a comprehensive test suite, it seems that it ought be possible to
> use the actual execution of the test suite, under a trace hook
> perhaps, or something o
On Feb 9, 2008, at 8:27 PM, Brett Cannon wrote:
> On Feb 8, 2008 5:03 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On Feb 8, 2008 4:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> I recommend dropping the dict.copy() method from Py3.0.
>>>
>>> * We can already write: newd = copy.co
On Feb 8, 2008 5:03 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Feb 8, 2008 4:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I recommend dropping the dict.copy() method from Py3.0.
> >
> > * We can already write: newd = copy.copy(d).
> > * We can also write: newd = dict(d)
>
On Feb 8, 2008, at 7:51 PM, Raymond Hettinger wrote:
> I recommend dropping the dict.copy() method from Py3.0.
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
U
On Feb 8, 2008 4:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I recommend dropping the dict.copy() method from Py3.0.
>
> * We can already write: newd = copy.copy(d).
> * We can also write: newd = dict(d)
> * Both of those approaches also work for most other containers.
> * The collec
I recommend dropping the dict.copy() method from Py3.0.
* We can already write: newd = copy.copy(d).
* We can also write: newd = dict(d)
* Both of those approaches also work for most other containers.
* The collections.Mapping ABC does not support copy().
* copy() is not a universal feature o
45 matches
Mail list logo
