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
Greg Ewing wrote:
> Hmmm, that convention isn't very scalable. What happens
> when you update the API again -- do you use an _ex_ex
> suffix? :-)
How about a _ng suffix (next generation)? *scnr*
Christian
___
Python-3000 mailing list
Python-3000@python
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.
On Feb 10, 2008 4:57 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Yeah -- the _ex suffix on the name suggests that that's the API we
> > wanted but we'd already released a version with a suboptimal API...
>
> Hmmm, that convention isn't very scalable. What happens
> when
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(
Guido van Rossum wrote:
> Yeah -- the _ex suffix on the name suggests that that's the API we
> wanted but we'd already released a version with a suboptimal API...
Hmmm, that convention isn't very scalable. What happens
when you update the API again -- do you use an _ex_ex
suffix? :-)
Also it tend
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 Feb 10, 2008 1:01 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> In Py3.0, would it be worth it to simplify this protocol by combining these
> two methods? Always pass in a proto argument and the
> method can ignore it if it wants.
Yeah -- the _ex suffix on the name suggests that that's t
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
In Py3.0, would it be worth it to simplify this protocol by combining these two
methods? Always pass in a proto argument and the
method can ignore it if it wants.
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mai
>> [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
> Since there are discussions going on on the topic of allocation algorithms for
> various built-in types, I thought I'd mention there's a patch for turning
> unicode objects into variable-sized objects (rather than using a
> separately-allocated buffer). The aim is to make allocation of those obje
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 4:53 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Since there are discussions going on on the topic of allocation algorithms for
> various built-in types, I thought I'd mention there's a patch for turning
> unicode objects into variable-sized objects (rather than using a
> separa
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
Hi,
Since there are discussions going on on the topic of allocation algorithms for
various built-in types, I thought I'd mention there's a patch for turning
unicode objects into variable-sized objects (rather than using a
separately-allocated buffer). The aim is to make allocation of those objects
32 matches
Mail list logo
