On Jan 12, 2008, at 5:32 PM, Raymond Hettinger wrote:
> Not natural, just inefficient and cute. Also, there was no answer
> to the question about use cases.
Fair enough. I will present some use cases below.
> AFAICT, this feature has never been requested. The closest was a
> feature request f
[Raymond]
>>> When does it come-up that you want a third summed dict
>>> while keeping the two originals around unchanged? Does
>>> it matter that the addition is non-commutative? Would
>>> a + b + c produce an intermediate a/b combo and then
>>> another new object for a/b/c so that the entries i
On Jan 12, 2008 8:51 AM, Jared Flatow <[EMAIL PROTECTED]> wrote:
> > On Jan 11, 2008 5:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> When does it come-up that you want a third summed dict
> >> while keeping the two originals around unchanged? Does
> >> it matter that the addition is non
Jared Flatow wrote:
> p.s. If I were to get approval to implement some version of this,
> which version of Python would be appropriate to work with?
The minimum version is 2.6. 2.5 is in maintenance mode. Changes made to
2.6 are merged into 3.0 so you don't have to create two patches. It'd
stick
> On Jan 11, 2008 5:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> When does it come-up that you want a third summed dict
>> while keeping the two originals around unchanged? Does
>> it matter that the addition is non-commutative? Would
>> a + b + c produce an intermediate a/b combo and t
> I'd like to take an "all or nothing" approach to this: either we
> implement the same 4 operations as for sets (|, &, ^ and -) or we
> implement none of them. .
. . .
> I'm not sure where I stand on this proposal -- I guess a +0, if
> someone else does the work. (The abc.py module needs to be up
On Jan 11, 2008 5:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I wasn't suggesting that the result of concatenation would
> > be a chained table, rather that it would perform the
> > equivalent of an update and return the new dict
> >(the same way extend works for lists)
>
> When does
> I wasn't suggesting that the result of concatenation would
> be a chained table, rather that it would perform the
> equivalent of an update and return the new dict
>(the same way extend works for lists)
When does it come-up that you want a third summed dict
while keeping the two originals
On Jan 11, 2008, at 6:45 PM, Raymond Hettinger wrote:
> IMO, the chainmap() recipe on ASPN is a much better solution since
> it doesn't create a third dictionary with the all the attendant
> allocation and copying effort.
I wasn't suggesting that the result of concatenation would be a
chaine
[Jared]
> I think it would be convenient and pythonic if dict
> objects implemented the PySequence_Concat method.
IMO, the chainmap() recipe on ASPN is a much better solution since it doesn't
create a third dictionary with the all the attendant allocation and copying
effort. It isn't a common u
10 matches
Mail list logo
