Greg Ewing wrote:
Steven Bethard wrote:
py> def defaultdict(*args, **kwargs):
... defaultfactory, args = args[0], args[1:]
which can be written more succinctly as
def defaultdict(defaultfactory, *args, **kwargs):
...
Not if you want to allow the defaultfactory to be called with a keyword
Steven Bethard wrote:
py> def defaultdict(*args, **kwargs):
... defaultfactory, args = args[0], args[1:]
which can be written more succinctly as
def defaultdict(defaultfactory, *args, **kwargs):
...
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Z
Jack Diederich wrote:
On Sun, Mar 27, 2005 at 02:20:33PM -0700, Steven Bethard wrote:
Michele Simionato wrote:
I am surprised nobody suggested we put those two methods into a
separate module (say dictutils or even UserDict) as functions:
from dictutils import tally, listappend
tally(mydict, key)
On Sun, Mar 27, 2005 at 02:20:33PM -0700, Steven Bethard wrote:
> Michele Simionato wrote:
> >I am surprised nobody suggested we put those two methods into a
> >separate module (say dictutils or even UserDict) as functions:
> >
> >from dictutils import tally, listappend
> >
> >tally(mydict, key)
>
Michele Simionato wrote:
FWIW, here is my take on the defaultdict approach:
def defaultdict(defaultfactory, dictclass=dict):
class defdict(dictclass):
def __getitem__(self, key):
try:
return super(defdict, self).__getitem__(key)
except KeyError:
Michele Simionato wrote:
I am surprised nobody suggested we put those two methods into a
separate module (say dictutils or even UserDict) as functions:
from dictutils import tally, listappend
tally(mydict, key)
listappend(mydict, key, value)
Sorry to join the discussion so late (I've been away from
On Sat, 19 Mar 2005 01:24:57 GMT, rumours say that "Raymond Hettinger"
<[EMAIL PROTECTED]> might have written:
>I would like to get everyone's thoughts on two new dictionary methods:
>
>def count(self, value, qty=1):
>try:
>self[key] += qty
>except K
R.H.:
> The setdefault() method would continue to exist but
> would likely not make it into Py3.0.
I agee to remove the setdefault.
I like the new count method, but I don't like the appendlist method,
because I think it's too much specilized.
I too use sets a lot; recently I've suggested to add
Greg Ewing wrote:
Michele Simionato wrote:
def defaultdict(defaultfactory, dictclass=dict):
class defdict(dictclass):
def __getitem__(self, key):
try:
return super(defdict, self).__getitem__(key)
except KeyError:
return self.setdef
I agree -- I find myself NEEDING sets more and more. I use them with this
idiom quite often. Once they become more widely available (i.e. Python 2.3
is installed everywhere), I will use them almost as much as lists I bet.
So any solution IMO needs to at least encompass sets. But preferably
some
Michele Simionato wrote:
def defaultdict(defaultfactory, dictclass=dict):
class defdict(dictclass):
def __getitem__(self, key):
try:
return super(defdict, self).__getitem__(key)
except KeyError:
return self.setdefault(key, defaultf
Raymond Hettinger wrote:
I would like to get everyone's thoughts on two new dictionary methods:
def count(self, value, qty=1):
def appendlist(self, key, *values):
-1.0
When I need these, I just use subtype recipes. They seem way too
special-purpose for the base dict type.
class C
"Michele Simionato" <[EMAIL PROTECTED]> wrote:
> FWIW, here is my take on the defaultdict approach:
>
> def defaultdict(defaultfactory, dictclass=dict):
> class defdict(dictclass):
> def __getitem__(self, key):
> try:
> return super(defdict, self).__getitem_
FWIW, here is my take on the defaultdict approach:
def defaultdict(defaultfactory, dictclass=dict):
class defdict(dictclass):
def __getitem__(self, key):
try:
return super(defdict, self).__getitem__(key)
except KeyError:
return se
Raymond Hettinger wrote:
> I would like to get everyone's thoughts on two new dictionary
methods:
>
> def count(self, value, qty=1):
> try:
> self[key] += qty
> except KeyError:
> self[key] = qty
>
> def appendlist(self, key, *
Raymond,
I am +1 for both suggestions, tally and appendlist.
Extended:
> Also, in all of my code base, I've not run across a single opportunity to use
> something like unionset(). This is surprising because I'm the set() author
> and
> frequently use set based algorithms.Your example was
On Sun, 20 Mar 2005 15:14:22 -0800, David Eppstein
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz)
>wrote:
>
>> >I am surprised nobody suggested we put those two methods into a
>> >separate module (say dictutils or even UserDict) as functions:
>> >
>> >from di
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz)
wrote:
> >I am surprised nobody suggested we put those two methods into a
> >separate module (say dictutils or even UserDict) as functions:
> >
> >from dictutils import tally, listappend
> >
> >tally(mydict, key)
> >listappend(mydict, key,
In article <[EMAIL PROTECTED]>,
Michele Simionato <[EMAIL PROTECTED]> wrote:
>
>I am surprised nobody suggested we put those two methods into a
>separate module (say dictutils or even UserDict) as functions:
>
>from dictutils import tally, listappend
>
>tally(mydict, key)
>listappend(mydict, key, v
Reinhold Birkenfeld wrote:
I don't quite understand that. Which dict item are you extending? Don't
you need something like
dl[key].append("word")
Rigth. It was just a typo on my part. Thanks for fixing.
Mike
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I really do not like it. So -1 for me. Your two methods are very specialized
whereas the dict type is very generic. Usually, when I see something like
this in code, I can smell it's a patch to overcome some shortcomings on a
previous design, thereby making the economy of re-designing. Simpl
Beni Cherniavsky <[EMAIL PROTECTED]> writes:
>> The relatively recent "improvement" of the dict constructor signature
>> (``dict(foo=bar,...)``) obviously makes it impossible to just extend the
>> constructor to ``dict(default=...)`` (or anything else for that matter) which
>> would seem much less
Kay Schluehr wrote:
I think that's because you have to instantiate a different object for
each different key. Otherwise, you would instantiate just one list as
a default value for *all* default values.
Or the default value will be copied, which is not very hard either or
type(self._default)() will
On Sat, 19 Mar 2005 20:07:40 -0800, Kay Schluehr wrote:
> It is bad OO design, George. I want to be a bit more become more
> specific on this and provide an example:
Having thought about this for a bit, I agree it is a powerful
counter-argument and in many other languages I'd consider this a total
> Another option with no storage overhead which goes part way to reducing
> the awkwardness would be to provide a decorator class accessible through
> dict. The decorator class would take a value or function to be used as
> the default, but apart from __getitem__ would simply forward all other
> me
Paul Rubin wrote:
"El Pitonero" <[EMAIL PROTECTED]> writes:
What about no name at all for the scalar case:
a['hello'] += 1
a['bye'] -= 2
I like this despite the minor surprise that it works even when
a['hello'] is uninitialized.
+1
and if the value is a list:
a['hello']= [1, 2, 3]
a['hello']+= [4]
Matteo Dell'Amico wrote:
> Kay Schluehr wrote:
>
> > Why do You set
> >
> > d.defaultValue(0)
> > d.defaultValue(function=list)
> >
> > but not
> >
> > d.defaultValue(0)
> > d.defaultValue([])
> >
> > ?
>
> I think that's because you have to instantiate a different object for
> each different key.
Roose wrote:
> I think someone mentioned that it might be a problem to add another
> piece of state to all dicts though. I don't know enough about the
> internals to say anything about this.
>
> setdefault gets around this by having you pass in the value every
> time, so it doesn't have to store
I like count() and appendlist() or whatever they will be named. But I
have one question/idea:
Why does the methods have to be put in dict? Can't their be a subtype
of dict that includes those two methods? I.e.:
.histogram = counting_dict()
.for ch in text:
.histogram.count(ch)
Then maybe som
In article <[EMAIL PROTECTED]>, Raymond Hettinger wrote:
>I would like to get everyone's thoughts on two new dictionary methods:
>
>def count(self, value, qty=1):
>try:
>self[key] += qty
>except KeyError:
>self[key] = qty
Yes, yes, YE
Kay Schluehr wrote:
Why do You set
d.defaultValue(0)
d.defaultValue(function=list)
but not
d.defaultValue(0)
d.defaultValue([])
?
I think that's because you have to instantiate a different object for
each different key. Otherwise, you would instantiate just one list as a
default value for *all* d
Max wrote:
Has anyone _not_ heard Jeff Probst say, "I'll go tally the votes"?!
:)
Who is Jeff Probst?
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
Any takers for tally()?
Well, as a non-native speaker, I had to look up this one in my
dictionary. That said, it may be bad luck on my side, but it may be that
this word is relatively uncommon and there are many others who would be
h
Duncan Booth wrote:
> Raymond Hettinger wrote:
>
> > The rationale is to replace the awkward and slow existing idioms
for
> > dictionary based accumulation:
> >
> > d[key] = d.get(key, 0) + qty
> > d.setdefault(key, []).extend(values)
> >
>
> How about the alternative approach of allowing t
> How about the alternative approach of allowing the user to override the
> action to be taken when accessing a non-existent key?
>
>d.defaultValue(0)
I like this a lot. It makes it more clear from the code what is going on,
rather than having to figure out what the name appendlist, count, ta
George Sakkis wrote:
>> -1 form me.
>>
>> I'm not very glad with both of them ( not a naming issue ) because i
>> think that the dict type should offer only methods that apply to each
>> dict whatever it contains. count() specializes to dict values that are
>> addable and appendlist to those that a
John Machin wrote:
> Reinhold Birkenfeld wrote:
>> John Machin wrote:
>> Are you kidding? If you know what "set" and "default" means, you will
> be
>> able to guess what "setdefault" means. Same goes for updateBy.
>>
>
> No I'm not kidding -- people from some cultures have no difficulty at
> all i
Mike Rovner wrote:
> Paul Rubin wrote:
>
>> If the compiler can do some type inference, it can optimize out those
>> multiple calls pretty straightforwardly.
>
> It can be tipped like that:
>
> di = dict(int)
> di.setdefault(0)
> di[key] += 1
Interesting, but why do you need to give the int typ
Raymond Hettinger wrote:
I would like to get everyone's thoughts on two new dictionary methods:
def count(self, value, qty=1):
try:
self[key] += qty
except KeyError:
self[key] = qty
def appendlist(self, key, *values):
Raymond Hettinger wrote:
> The rationale is to replace the awkward and slow existing idioms for
> dictionary based accumulation:
>
> d[key] = d.get(key, 0) + qty
> d.setdefault(key, []).extend(values)
>
How about the alternative approach of allowing the user to override the
action to b
Mike Rovner <[EMAIL PROTECTED]> writes:
> It can be tipped like that:
>
> di = dict(int)
> di.setdefault(0)
> di[key] += 1
...
> But the point is that if method not found in dict it delegated to
> container type specified in constructor.
>
> It solves dict specialization without bloating dict cla
Paul Rubin wrote:
If the compiler can do some type inference, it can optimize out those
multiple calls pretty straightforwardly.
It can be tipped like that:
di = dict(int)
di.setdefault(0)
di[key] += 1
dl = dict(list)
dl.setdefault([])
dl.append("word")
dl.extend(mylist)
But the point is that if me
*pling* !
I'm sometimes a bit slow :)
Regards Kay
--
http://mail.python.org/mailman/listinfo/python-list
"Michael Spencer" <[EMAIL PROTECTED]> wrote:
> I could imagine a class: accumulator(mapping, default, incremetor) such that:
> >>> my_tally = accumulator({}, 0, operator.add)
> or
> >>> my_dict_of_lists = accumulator({}, [], list.append)
> or
> >>> my_dict_of_sets = accumulator({}, set(),
On Sat, 19 Mar 2005 01:24:57 GMT, "Raymond Hettinger"
<[EMAIL PROTECTED]> wrote:
>def count(self, value, qty=1):
>try:
>self[key] += qty
>except KeyError:
>self[key] = qty
>
>def appendlist(self, key, *values):
>tr
> > +1 on this. The new suggested operations are meaningful for a subset
> of all
> > valid dicts, so they
> > should not be part of the base dict API. If any version of this is
> approved, > it will clearly be an
> > application of the "practicality beats purity" zen rule, and the
> > justificatio
I am surprised nobody suggested we put those two methods into a
separate module (say dictutils or even UserDict) as functions:
from dictutils import tally, listappend
tally(mydict, key)
listappend(mydict, key, value)
I am -1 about a specific subclass of dict in the standard library, I
would not
Kay Schluehr wrote:
Maybe also the subclassing idea I introduced falls for short for the
same reasons. Adding an accumulator to a dict should be implemented as
a *decorator* pattern in the GoF meaning of the word i.e. adding an
interface to some object at runtime that provides special facilities.
U
George Sakkis wrote:
> > -1 form me.
> >
> > I'm not very glad with both of them ( not a naming issue ) because
i
> > think that the dict type should offer only methods that apply to
each
> > dict whatever it contains. count() specializes to dict values that
are
> > addable and appendlist to those
"John Machin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> George Sakkis wrote:
> > +1 on this. The new suggested operations are meaningful for a subset
> of all valid dicts, so they
> > should not be part of the base dict API. If any version of this is
> approved, it will clearl
Alexander Schmolck wrote:
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
The rationale is to replace the awkward and slow existing idioms for dictionary
based accumulation:
d[key] = d.get(key, 0) + qty
d.setdefault(key, []).extend(values)
Indeed not too readable. The try..except version is
George Sakkis wrote:
> +1 on this. The new suggested operations are meaningful for a subset
of all valid dicts, so they
> should not be part of the base dict API. If any version of this is
approved, it will clearly be an
> application of the "practicality beats purity" zen rule, and the
justificat
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> The rationale is to replace the awkward and slow existing idioms for
> dictionary
> based accumulation:
>
> d[key] = d.get(key, 0) + qty
> d.setdefault(key, []).extend(values)
>
> In simplest form, those two statements would now be coded m
Michael Spencer wrote:
> Raymond Hettinger wrote:
> > I would like to get everyone's thoughts on two new dictionary
methods:
> >
> > def count(self, value, qty=1):
> > try:
> > self[key] += qty
> > except KeyError:
> > self[key] = qty
Raymond Hettinger wrote:
I would like to get everyone's thoughts on two new dictionary methods:
def count(self, value, qty=1):
try:
self[key] += qty
except KeyError:
self[key] = qty
def appendlist(self, key, *values):
> -1 form me.
>
> I'm not very glad with both of them ( not a naming issue ) because i
> think that the dict type should offer only methods that apply to each
> dict whatever it contains. count() specializes to dict values that are
> addable and appendlist to those that are extendable. Why not
> su
On 19 Mar 2005 11:33:20 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>Raymond Hettinger wrote:
>> I would like to get everyone's thoughts on two new dictionary
>methods:
>>
>> def count(self, value, qty=1):
>> try:
>> self[key] += qty
>> except K
In article <[EMAIL PROTECTED]>,
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> Also, in all of my code base, I've not run across a single opportunity to use
> something like unionset().
In my code, this would be roughly tied with appendlist for frequency of
use.
--
David Eppstein
Computer
In article <[EMAIL PROTECTED]>,
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> The rationale is to replace the awkward and slow existing idioms for
> dictionary
> based accumulation:
>
> d[key] = d.get(key, 0) + qty
> d.setdefault(key, []).extend(values)
>
> In simplest form, those t
[Bengt Richter]
> IMO Raymond's Zen concerns
> are the ones to think about first, and then efficiency, which was one of the
motivators
> in the first place ;-)
Well said.
I find the disassembly (presented in the first post) to be telling. The
compiler has done a great job and there is no fluff -
Reinhold Birkenfeld wrote:
> John Machin wrote:
> Are you kidding? If you know what "set" and "default" means, you will
be
> able to guess what "setdefault" means. Same goes for updateBy.
>
No I'm not kidding -- people from some cultures have no difficulty at
all in mentally splitting up "words"
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I find the disassembly (presented in the first post) to be telling.
> The compiler has done a great job and there is no fluff -- all of
> those steps have been specified by the programmer and he/she must at
> some level be aware of every one of them
John Machin wrote:
> Raymond Hettinger wrote:
>> I would like to get everyone's thoughts on two new dictionary
> methods:
>
> +1 for each.
>
>> PROBLEMS BEING SOLVED
>> -
>>
>> The readability issues with the existing constructs are:
>>
>> * They are awkward to teach, create,
Raymond Hettinger wrote:
> I would like to get everyone's thoughts on two new dictionary
methods:
+1 for each.
> PROBLEMS BEING SOLVED
> -
>
> The readability issues with the existing constructs are:
>
> * They are awkward to teach, create, read, and review.
> * Their wording
On Sat, 19 Mar 2005 07:13:15 -0500, Kent Johnson <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Sat, 19 Mar 2005 01:24:57 GMT, "Raymond Hettinger" <[EMAIL PROTECTED]>
>> wrote:
>>
>>>I would like to get everyone's thoughts on two new dictionary methods:
>>>
>>> def count(self, valu
"El Pitonero" <[EMAIL PROTECTED]> writes:
> What about no name at all for the scalar case:
>
> a['hello'] += 1
> a['bye'] -= 2
I like this despite the minor surprise that it works even when
a['hello'] is uninitialized.
--
http://mail.python.org/mailman/listinfo/python-list
Raymond Hettinger wrote:
> I would like to get everyone's thoughts on two new dictionary
methods:
>
> def count(self, value, qty=1):
> try:
> self[key] += qty
> except KeyError:
> self[key] = qty
>
> def appendlist(self, key, *
On Sat, 19 Mar 2005 15:17:59 GMT,
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Dan Sommers]
>> Curious that in this lengthy discussion, a method name of
>> "accumulate" never came up. I'm not sure how to separate the two
>> cases (accumulating scalars vs. accumulating a list), though.
> Se
George Sakkis wrote:
> "Aahz" <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > >
> > >The proposed names could possibly be improved (perhaps tally() is
more active
> > >and clear than count()).
> >
> > +1 tally()
>
> -1 for count():
"Aahz" <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >
> >The proposed names could possibly be improved (perhaps tally() is more active
> >and clear than count()).
>
> +1 tally()
-1 for count(): Implies an accessor, not a mutator.
-1
Raymond Hettinger wrote:
>
> As written out above, the += syntax works fine but does not work with
append().
> ...
> BTW, there is no need to make the same post three times.
The append() syntax works, if you use the other definition of safedict
(*). There are more than one way of defining safedict
Hi
if key not in d:
d[key] = {subkey:value}
else:
d[key][subkey] = value
and
d[(key,subkey)] = value
?
Michel Claveau
--
http://mail.python.org/mailman/listinfo/python-list
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Jeff Epler]
> > Maybe something for sets like 'appendlist' ('unionset'?)
>
> While this could work and potentially be useful, I think it is better to keep
> the proposal focused on the two common use cases. Adding a third would reduce
> the chance
Kent Johnson said unto the world upon 2005-03-19 07:19:
Brian van den Broek wrote:
Raymond Hettinger said unto the world upon 2005-03-18 20:24:
I would like to get everyone's thoughts on two new dictionary methods:
def appendlist(self, key, *values):
try:
self[ke
[El Pitonero]
> Is it even necessary to use a method name?
>
> import copy
> class safedict(dict):
> def __init__(self, default=None):
> self.default = default
> def __getitem__(self, key):
> try:
> return dict.__getitem__(self, key)
> except KeyError:
>
In article <[EMAIL PROTECTED]>,
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>How about countkey() or tabulate()?
Those rank roughly equal to tally() for me, with a slight edge to these
two for clarity and a slight edge to tally() for conciseness.
--
Aahz ([EMAIL PROTECTED]) <*>
Raymond Hettinger wrote:
> Separating the two cases is essential. Also, the wording should
contain strong
> cues that remind you of addition and of building a list.
>
> For the first, how about addup():
>
> d = {}
> for word in text.split():
> d.addup(word)
import copy
class safe
In article <[EMAIL PROTECTED]>,
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>The proposed names could possibly be improved (perhaps tally() is more active
>and clear than count()).
+1 tally()
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"The joy of coding Pyth
-1 on set increment.
I think this makes your intent much clearer:
.d={}
.for word in text.split():
.d.tally(word)
.if word.lower() in ["a","an","the"]:
.d.tally(word,-1)
or perhaps simplest:
.d={}
.for word in text.split():
.if word.lower() not in ["a","an","the"]:
.d
[Ivan Van Laningham]
> What about adding another method, "setincrement()"?
. . .
> Not that there's any real utility in that.
That was a short lived suggestion ;-)
Also, it would entail storing an extra value in the dictionary header. That
alone would be a killer.
Raymond
--
http://mail.
Dan Sommers wrote:
> On Sat, 19 Mar 2005 01:24:57 GMT,
> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
>
> > The proposed names could possibly be improved (perhaps tally() is
more
> > active and clear than count()).
>
> Curious that in this lengthy discussion, a method name of
"accumulate"
> never
Hi All--
Raymond Hettinger wrote:
>
> Separating the two cases is essential. Also, the wording should contain
> strong
> cues that remind you of addition and of building a list.
>
> For the first, how about addup():
>
> d = {}
> for word in text.split():
> d.addup(word)
>
I
On 18 Mar 2005 21:03:52 -0800 Michele Simionato wrote:
MS> +1 for inc instead of count.
MS> appendlist seems a bit too specific (I do not use dictionaries of
MS> lists that often).
inc is too specific too.
MS> The problem with setdefault is the name, not the functionality.
The problem with func
[Dan Sommers]
> Curious that in this lengthy discussion, a method name of "accumulate"
> never came up. I'm not sure how to separate the two cases (accumulating
> scalars vs. accumulating a list), though.
Separating the two cases is essential. Also, the wording should contain strong
cues that re
[Jeff Epler]
> Maybe something for sets like 'appendlist' ('unionset'?)
While this could work and potentially be useful, I think it is better to keep
the proposal focused on the two common use cases. Adding a third would reduce
the chance of acceptance.
Also, in all of my code base, I've not run
Reinhold Birkenfeld wrote:
Peter Hansen wrote:
+1 for add and, given the above, I'm unsure there's
a viable alternative (unless this is restricted to
positive values, or perhaps even to "+1" specifically).
What about `addto()'? add() just has the connotation of adding something
to the dict and not
Peter Hansen wrote:
> Michele Simionato wrote:
>> +1 for inc instead of count.
>
> -1 for inc, increment, or anything that carries a
> connotation of *increasing* the value, so long as
> the proposal allows for negative numbers to be
> involved. "Incrementing by -1" is a pretty silly
> picture.
>
Michele Simionato wrote:
+1 for inc instead of count.
-1 for inc, increment, or anything that carries a
connotation of *increasing* the value, so long as
the proposal allows for negative numbers to be
involved. "Incrementing by -1" is a pretty silly
picture.
+1 for add and, given the above, I'm un
Hi All--
Raymond Hettinger wrote:
>
> [Michele Simionato]
> > +1 for inc instead of count.
>
> Any takers for tally()?
>
Sure. Given the reasons for avoiding add(), tally()'s a much better
choice than count().
What about d.tally(key,0) then? Deleting the key as was suggested by
Michael Spen
> [Jeff Epler]
> > Maybe something for sets like 'appendlist' ('unionset'?)
>
On Sat, Mar 19, 2005 at 04:18:43AM +, Raymond Hettinger wrote:
> I do not follow. Can you provide a pure python equivalent?
Here's what I had in mind:
$ python /tmp/unionset.py
Set(['set', 'self', 'since', 's', 's
On Sat, 19 Mar 2005 01:24:57 GMT,
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> The proposed names could possibly be improved (perhaps tally() is more
> active and clear than count()).
Curious that in this lengthy discussion, a method name of "accumulate"
never came up. I'm not sure how to se
Ivan Van Laningham a écrit :
Hi All--
Maybe I'm not getting it, but I'd think a better name for count would be
add. As in
d.add(key)
d.add(key,-1)
d.add(key,399)
etc.
>
[...]
There is no existing add() method for dictionaries. Given the name
change, I'd like to see it.
Metta,
Ivan
I don't think "
Brian van den Broek wrote:
Raymond Hettinger said unto the world upon 2005-03-18 20:24:
I would like to get everyone's thoughts on two new dictionary methods:
def appendlist(self, key, *values):
try:
self[key].extend(values)
except KeyError:
Raymond Hettinger wrote:
> I would like to get everyone's thoughts on two new dictionary
methods:
>
> def count(self, value, qty=1):
> try:
> self[key] += qty
> except KeyError:
> self[key] = qty
>
> def appendlist(self, key,
Bengt Richter wrote:
On Sat, 19 Mar 2005 01:24:57 GMT, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
I would like to get everyone's thoughts on two new dictionary methods:
def count(self, value, qty=1):
try:
self[key] += qty
except KeyError:
se
On Sat, 19 Mar 2005 01:24:57 GMT, "Raymond Hettinger"
<[EMAIL PROTECTED]> wrote:
>I would like to get everyone's thoughts on two new dictionary methods:
>
>def count(self, value, qty=1):
>try:
>self[key] += qty
>except KeyError:
>self[
Roose wrote:
> Not to belabor the point, but in the example on that page, max(L, key=len)
> could be written max(len(x) for x in L).
No, it can't:
Python 2.5a0 (#2, Mar 5 2005, 17:44:37)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>
> Py2.5 is already going to include any() and all() as builtins. The
signature
> does not include a function, identity or otherwise. Instead, the caller
can
> write a listcomp or genexp that evaluates to True or False:
Actually I was just looking at Python 2.5 docs since you mentioned this.
htt
[Michele Simionato]
> Dunno, to me "tally" reads "counts the numbers of votes for a candidate
> in an election".
That isn't a pleasant image ;-)
>The
> only right name would be "get_and_possibly_set" but it is a bit long to
> type.
>
>> Even if a wording is found that better describes the both
> Py2.5 is already going to include any() and all() as builtins. The
signature
> does not include a function, identity or otherwise. Instead, the caller
can
> write a listcomp or genexp that evaluates to True or False:
>
> any(x >= 42 for x in data)
>
> If you wanted an identify function, tha
1 - 100 of 122 matches
Mail list logo
