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
- 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
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 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 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
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
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
[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 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
[email protected]
http
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
> 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
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
[email protected]
http://mail.python.org/mai
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
>> [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
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
[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
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
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
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
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 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(
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 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
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.
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
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
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 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
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
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
32 matches
Mail list logo
