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:
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
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
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
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
[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 iter
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.
For one
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 import
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 typing
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 closely
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 are a sure cure
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
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:
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)
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
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. iter could
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)
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
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:
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
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 a
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 KeyError:
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 a
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):
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
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__(key)
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
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,
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
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
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 class and is
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 be
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):
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 type to the
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 in mentally
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 are
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,
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 the user to
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
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
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*
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, YES!
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
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 it.
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. Otherwise, you would
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]
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
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
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
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 ad hoc.
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.
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
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, value)
That
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, value)
That
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 dictutils import
Raymond Hettinger:
Any takers for tally()?
Dunno, to me tally reads counts the numbers of votes for a candidate
in an election.
We should avoid abbreviations like inc() or incr() that different
people tend to
abbreviate differently (for example, that is why the new partial()
function has
its
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
happier with
[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 the get and
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)
[Roose]
Oh great, I just saw that.
. .
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.
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.
max([a,
[Roose]
Actually I was just looking at Python 2.5 docs since you mentioned this.
http://www.python.org/dev/doc/devel/whatsnew/node3.html
It says min() and max() will gain a key function parameter, and sort()
gained one in Python 2.4 (news to me).
It also appears in itertools.groupby() and,
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[key] = qty
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:
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,
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:
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 separate
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
[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', 'sys',
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 Spencer
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
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.
+1 for
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
[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
[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 remind
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
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 still
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 came up. I'm
[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
--
-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]:
.
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 Python should
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
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]) *
[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:
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:
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 of
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 =
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 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,
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 for tally():
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(): Implies an accessor, not a
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.
Separating the
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):
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
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, value, qty=1):
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 tends
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, read, and review.
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
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 like
[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 --
1 - 100 of 134 matches
Mail list logo
