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
Ville Vainio wrote:
The issue that really bothers me here is bloating the builtin
space. We already have an uncomfortable amount of builtin
functions.
Maybe what we're really after here is the notion of a
builtin module that's pre-imported into the builtin
namespace.
--
Greg Ewing, Computer Science
Steven Bethard wrote:
I'd argue that for the same reasons that
dict.fromkeys is a dict classmethod, the itertools methods could be iter
classmethods (or staticmethods). The basic idea being that it's nice to
place the methods associated with a type in that type's definiton. The
parallel's a l
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
Ville Vainio wrote:
A minimal set would not be that offensive, yes. But then we would have
two places to look for itertools functionality, which may not be
desirable.
True, though this is currently necessary with str objects if you want to
use, say string.maketrans, so it's not without some prece
> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:
Steven> Certainly a valid point. How would you feel about adding
Steven> just a select few itertools functions, perhaps just
Steven> islice, chain and tee?
A minimal set would not be that offensive, yes. But then we would h
Ville Vainio wrote:
The issue that really bothers me here is bloating the builtin
space. We already have an uncomfortable amount of builtin
functions. Of course the additions that have been suggested would not
pollute the builtin namespace, but they would still be there, taking
space. I'd rather se
> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:
Steven> to be documented as a builtin type. I don't find the
Steven> argument "builtin type methods are hard to find"
Steven> convincing -- the solution here is to fix the
Steven> documentation, not refuse to add builtin
Terry Reedy wrote:
But if classmethods are intended to provide alternate constructors
But I do not remember that being given as a reason for classmethod(). But
I am not sure what was.
Well I haven't searched thoroughly, but I know one place that it's
referenced is in descrintro[1]:
"Factoid: __
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Steven Bethard" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>>True it's not a huge win. But I'd argue that for the same reasons that
>>>dict.fromkeys is a dict classmeth
Terry Reedy wrote:
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
True it's not a huge win. But I'd argue that for the same reasons that
dict.fromkeys is a dict classmethod, the itertools methods could be iter
classmethods (or staticmethods).
As near as I could te
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> True it's not a huge win. But I'd argue that for the same reasons that
> dict.fromkeys is a dict classmethod, the itertools methods could be iter
> classmethods (or staticmethods).
As near as I could tell from the
On Tue, 29 Mar 2005 11:32:33 -0800, Michael Spencer <[EMAIL PROTECTED]> wrote:
[...]
>While we're on the topic, what do you think of having unary, non-summary
>builtins automatically map themselves when called with an iterable that would
>otherwise be an illegal argument:
That last "otherwise" is
On Tue, Mar 29, 2005 at 12:38:42PM +0300, Ville Vainio wrote:
> > "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
>
> Raymond> If the experience works out, then all you're left with is
> Raymond> the trivial matter of convincing Guido that function
> Raymond> attributes
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> I guess the real questions are[1]:
> * How much does iter feel like a type?
> * How closely are the itertools functions associated with iter?
>
> STeVe
>
> [1] There's also the question of how much you believe in OO tenets like
> "functions
Steven Bethard wrote:
Ville Vainio wrote:
"Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of ty
Ville Vainio wrote:
"Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of typing
Raymond> impo
> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of typing
Raymond> import statements.
[Jack Diederich]
> > itertools to iter transition, huh? I slipped that one in, I mentioned
> > it to Raymond at PyCon and he didn't flinch. It would be nice not to
> > have to sprinkle 'import itertools as it' in code. iter could also
> > become a type wrapper instead of a function, so an it
In article <[EMAIL PROTECTED]>,
Jack Diederich <[EMAIL PROTECTED]> wrote:
> I only included making iter a type to make it more symmetric with str
> being a type. iter is currently a function, as a practical matter I wouldn't
> mind if it doubled as a namespace but that might make others flinch.
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 Mon, Mar 28, 2005 at 10:28:29AM -0700, Steven Bethard wrote:
> Jack Diederich wrote:
> >
> > itertools to iter transition, huh? I slipped that one in, I mentioned
> > it to Raymond at PyCon and he didn't flinch. It would be nice not to
> > have to sprinkle 'import itertools as it' in code. it
Jack Diederich wrote:
>
> itertools to iter transition, huh? I slipped that one in, I mentioned
> it to Raymond at PyCon and he didn't flinch. It would be nice not to
> have to sprinkle 'import itertools as it' in code. iter could also
> become a type wrapper instead of a function, so an iter in
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
Ah OK, I stand corrected. Whoops. I just read the web page and thought the
wrong thing, that makes sense.
> Think about it. A key= function is quite a different thing. It provides
a
> *temporary* comparison key while retaining the original value. IOW, your
> re-write is incorrect:
>
> >>> L =
"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
1 - 100 of 146 matches
Mail list logo
