> >> d.get(key, [], True).append(value)
> >
> > hmm. are you sure you didn't just reinvent setdefault ?
>
> I'm reasonably sure I copied it on purpose, only with a name that isn't 100%
> misleading as to what it does ;)
Heh. From the original Usenet posting that suggested the capability
that
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> However, I'm beginning to think we shouldn't be comparing them.
> defaultdict is a powerful but heavyweight option, intended for
> complicated behavior.
Check out Guido's patch. It's not that "heavyweight", and its intended
behavior is to make some opera
On Fri, 2006-02-17 at 11:09 -0800, Guido van Rossum wrote:
> Thanks for all the constructive feedback. Here are some responses and
> a new proposal.
>
> - Yes, I'd like to kill setdefault() in 3.0 if not sooner.
A worthy goal, but not possible unless you want to break existing code.
I don't thin
On Sat, 2006-02-18 at 12:53 +0100, Pierre Barbier de Reuille wrote:
> > Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> > Guido> dict with this behavior (but implemented in C) would be a good
> > Guido> addition to the language.
I agree that .setdefault() is a w
On 2/20/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Adam Olsen asked:
> > ... d.getorset(key, func) would work in your use cases?
>
> It is an improvement over setdefault, because it doesn't
> always evaluate the expensive func. (But why should every
> call have to pass in the function, when it is
On Mon, Feb 20, 2006, Alex Martelli wrote:
> On Feb 20, 2006, at 12:38 PM, Aahz wrote:
> ...
>>> Can you say, for the record (since nobody else seems to care), if
>>> d.getorset(key, func) would work in your use cases?
>>
>> Because I haven't been reading this thread all that closely, you'll
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
>> Can you say, for the record (since nobody else seems to care), if
>> d.getorset(key, func) would work in your use cases?
>
> Because I haven't been reading this thread all that closely, you'll
> have
> to remind me what this means.
Roughly the
On 2/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > Can you say, for the record (since nobody else seems to care), if
> > d.getorset(key, func) would work in your use cases?
>
> It doesn't work for the multiset/accumulation case:
>
> dd[key] += 1
On Mon, Feb 20, 2006, Adam Olsen wrote:
> On 2/20/06, Aahz <[EMAIL PROTECTED]> wrote:
>> On Sun, Feb 19, 2006, Josiah Carlson wrote:
>>>
>>> I agree, there is nothing perfect. But at least in all of my use-cases,
>>> and the majority of the ones I've seen 'in the wild', my previous post
>>> provid
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> Can you say, for the record (since nobody else seems to care), if
> d.getorset(key, func) would work in your use cases?
It doesn't work for the multiset/accumulation case:
dd[key] += 1
- Josiah
___
Pytho
Adam Olsen asked:
> ... d.getorset(key, func) would work in your use
> cases?
It is an improvement over setdefault, because it
doesn't always evaluate the expensive func. (But
why should every call have to pass in the function,
when it is a property of the dictionary?)
It doesn't actually *solve
On 2/20/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 19, 2006, Josiah Carlson wrote:
> >
> > I agree, there is nothing perfect. But at least in all of my use-cases,
> > and the majority of the ones I've seen 'in the wild', my previous post
> > provided an implementation that worked precisely
On Sun, Feb 19, 2006, Josiah Carlson wrote:
>
> I agree, there is nothing perfect. But at least in all of my use-cases,
> and the majority of the ones I've seen 'in the wild', my previous post
> provided an implementation that worked precisely like desired, and
> precisely like a regular dictionar
On 2/19/06, Steve Holden <[EMAIL PROTECTED]> wrote:
> > You are missing the rationale of the PEP process. The point is
> > *not* documentation. The point of the PEP process is to channel
> > and collect discussion, so that the BDFL can make a decision.
> > The BDFL is not bound at all to the PEP pr
"Michael Urman" <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > My post probably hasn't convinced you, but much of the confusion, I
> > believe, is based on Martin's original belief that 'k in dd' should
> > always return true if there is a default. One c
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [Terry Reedy]
>> One is a 'universal dict' that maps every key to something -- the
>> default if
>> nothing else. That should not have the default ever explicitly entered.
>> Udict.keys() should only give the keys
Michael Urman wrote:
> On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>>My post probably hasn't convinced you, but much of the confusion, I
>>believe, is based on Martin's original belief that 'k in dd' should
>>always return true if there is a default. One can argue that way, but
>>then
On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> My post probably hasn't convinced you, but much of the confusion, I
> believe, is based on Martin's original belief that 'k in dd' should
> always return true if there is a default. One can argue that way, but
> then you end up on the circula
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Martin v. Löwis]
> > This kind of invariant doesn't take into account
> > that there might be a default value.
>
> Precisely. Therefore, a defaultdict subclass violates the Liskov
> Substitution
> Principle.
class defaultdict(dict):
def __g
[Terry Reedy]
> One is a 'universal dict' that maps every key to something -- the default if
> nothing else. That should not have the default ever explicitly entered.
> Udict.keys() should only give the keys *not* mapped to the universal value.
Would you consider it a mapping invariant that "k
Raymond Hettinger wrote:
>> If you have a default value, you cannot ultimately del a key. This
>> sequence is *not* a basic mapping invariant.
>
>
> You believe that key deletion is not basic to mappings?
No, not in the sense that the key will go away through deletion.
I view a mapping as a modi
[Martin v. Löwis]
> If you have a default value, you cannot ultimately del a key. This
> sequence is *not* a basic mapping invariant.
You believe that key deletion is not basic to mappings?
> This kind of invariant doesn't take into account
> that there might be a default value.
Precisely. The
Raymond Hettinger wrote:
>>>Also, I think has_key/in should return True if there is a default.
> * if __contains__ always returns True, then it is a useless feature (since
> scripts containing a line such as "if k in dd" can always eliminate that line
> without affecting the algorithm).
If you m
> Quoting [EMAIL PROTECTED]:
>> The only question in my mind is whether or not getting a non-existent
>> value
>> under the influence of a given default value should stick that value in
>> the
>> dictionary or not.
It seems to me that there are at least two types of default dicts, which
have op
Martin v. Löwis wrote:
> Adam Olsen wrote:
>
>>Still -1. It's better, but it violates the principle of encapsulation
>>by mixing how-you-use-it state with what-it-stores state. In doing
>>that it has the potential to break an API documented as accepting a
>>dict. Code that expects d[key] to rai
> > Also, I think has_key/in should return True if there is a default.
> It certainly seems desirable to see True where d[some_key]
> doesn't raise an exception, but one could argue either way.
Some things can be agreed by everyone:
* if __contains__ always returns True, then it is a useless fea
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bengt Richter wrote:
>
> > My guess is that realistically default_factory will be used
> > to make clean code for filling a dict, and then turning the factory
> > off if it's to be passed into unknown contexts.
>
> This suggests that maybe the autodict beh
Guido van Rossum wrote:
> On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>Over lunch with Alex Martelli, he proposed that a subclass of dict
>>with this behavior (but implemented in C) would be a good addition to
>>the language. It looks like it wouldn't be hard to implement. It could
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>
>>Feedback?
>
>
> I would like this to be part of the standard dictionary type,
> rather than being a subtype.
>
> d.setdefault([]) (one argument) should install a default value,
> and d.cleardefault() should remove that setting; d.default
> sh
On Sat, 18 Feb 2006 10:44:15 +0100 (CET), "=?iso-8859-1?Q?Walter_D=F6rwald?="
<[EMAIL PROTECTED]> wrote:
>Guido van Rossum wrote:
>> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>> Guido van Rossum wrote:
>>> > d =3D {}
>>> > d.default_factory =3D set
>>> > ...
>>> > d[key].add(value)
>>>
Bengt Richter wrote:
> My guess is that realistically default_factory will be used
> to make clean code for filling a dict, and then turning the factory
> off if it's to be passed into unknown contexts.
This suggests that maybe the autodict behaviour shouldn't
be part of the dict itself, but prov
[Greg Ewing]
> Would people perhaps feel better if defaultdict
> *wasn't* a subclass of dict, but a distinct mapping
> type of its own? That would make it clearer that it's
> not meant to be a drop-in replacement for a dict
> in arbitrary contexts.
Absolutely. That's the right way to avoid Liskov
Would people perhaps feel better if defaultdict
*wasn't* a subclass of dict, but a distinct mapping
type of its own? That would make it clearer that it's
not meant to be a drop-in replacement for a dict
in arbitrary contexts.
Greg
___
Python-Dev mailing
At 01:44 PM 02/18/2006 -0500, James Y Knight wrote:
>On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> > I don't understand. In the rationale of PEP 333, it says
> > "The rationale for requiring a dictionary is to maximize portability
> > between servers. The alternative would be to define some
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> If the __getattr__()-like operation that supplies and inserts a
> dynamic default was a separate method, we wouldn't have this problem.
Why implement it in the dictionary type at all? If, for intance, the
default value functionality were provided
On 2/18/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> > Well, as you say: you get a KeyError if there is an error with the
> > key.
> > With a default_factory, there isn't normally an error with the key.
>
> But there should be. Consider the c
James Y Knight wrote:
> But there should be. Consider the case of two servers. One which takes
> all the items out of the dictionary (using items()) and puts them in
> some other data structure. Then it checks if the "Date" header has been
> set. It was not, so it adds it. Consider another simi
On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> I don't understand. In the rationale of PEP 333, it says
> "The rationale for requiring a dictionary is to maximize portability
> between servers. The alternative would be to define some subset of a
> dictionary's methods as being the standard a
Quoting [EMAIL PROTECTED]:
>
> Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> Guido> dict with this behavior (but implemented in C) would be a good
> Guido> addition to the language.
>
> Instead, why not define setdefault() the way it should have been done in th
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise excepti
Guido van Rossum wrote:
> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > d = {}
>> > d.default_factory = set
>> > ...
>> > d[key].add(value)
>>
>> Another option would be:
>>
>>d = {}
>>d.default_factory = set
>>d.get_default(key).add(value)
>>
>> Unl
Adam Olsen wrote:
> Demo/metaclass/Meta.py:55
That wouldn't break. If you had actually read the code, you would have
seen it is
try:
ga = dict['__getattr__']
except KeyError:
pass
How would it break if dict had a default factory? ga would get the
__getattr
Ian Bicking wrote:
> Well, here's a kind of an example: WSGI specifies that the environment
> must be a dictionary, and nothing but a dictionary. I think it would
> have to be updated to say that it must be a dictionary with
> default_factory not set, as default_factory would break the
> predictab
Guido van Rossum wrote:
> I'd much rather be able to write "if key in d" and get the result I want...
Somewhere else in this byzantine thread, I realised that what was really
bothering me was the conditional semantics that dict ended up with (i.e., it's
behaviour changed significantly if the def
On Fri, 17 Feb 2006, Phillip J. Eby wrote:
> > d = {} # or dict()
> > d.default_factory = list
>
> Why not a classmethod constructor:
>
> d = dict.with_factory(list)
>
> But I'd rather set the default and create the
> dictionary in one operation, since when reading it as two, you first
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
I agree with the gut feeling that these should still do the same
thing. Could we modify d.get() instead?
On Sat, 18 Feb 2006 00:52:51 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Adam Olsen wrote:
>> Consider these two pieces of code:
>>
>> if key in d:
>> dosomething(d[key])
>> else:
>> dosomethingelse()
>>
>> try:
>> dosomething(d[key])
>> except KeyError:
On 2/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> And this is where the question of whether has_key/__having__ return True or
> False when default_factory is set is important. If they return False, then the
> LBYL (if key in d:) and EAFTP (try/except) approaches give *different
> answers*.
>
>
At 11:58 AM 02/17/2006 -0800, Guido van Rossum wrote:
>I forgot to mention in my revised proposal that the API for setting
>the default_factory is slightly odd:
>
> d = {} # or dict()
> d.default_factory = list
>
>rather than
>
> d = dict(default_factory=list)
>
>This is of course because w
Guido van Rossum wrote:
> But there were
> several suggestions that this would be fine functionality to add to
> the standard dict type -- and then I really don't see any other way to
> do this.
Given the constructor problem, and the issue with "this function expects a
plain dictionary", I think
Adam Olsen wrote:
> And the pièce de résistance..
> Doc/tools/anno-api.py:51
>
> It has this:
> try:
> info = rcdict[s]
> except KeyError:
> sys.stderr.write("No refcount data for %s\n" % s)
> else:
> ...
> rcdict is loaded from refcounts.load(). refcounts.load
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > You could pass a float in as well. But if the function is documented
> > as taking a dict, and the programmer expects a dict.. that now has to
> > be changed to "dict without a default". Or they have to code
> > defe
Martin v. Löwis wrote:
> Adam Olsen wrote:
>
>>Consider these two pieces of code:
>>
>>if key in d:
>> dosomething(d[key])
>>else:
>> dosomethingelse()
>>
>>try:
>> dosomething(d[key])
>>except KeyError:
>> dosomethingelse()
>>
>>Before they were the same (assuming dosomething() won't raise
>>
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That's why I think has_key and in should return True for any key.
> This leaves keys(), items(), and values(). From a pure point of
> view, they should return infinite sets. Practicality beats purity,
> so yes, d[k] could be considered a mo
Ian Bicking wrote:
> It is lazily incarnated for multidict, because there is no *noticeable*
> side effect -- if there is any internal side effects that is an
> implementation detail. However for default_factory=list, the result of
> .keys(), .has_key(), and .items() changes when you do d[some_key
Adam Olsen wrote:
> Consider these two pieces of code:
>
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
>
> Before they were the same (assuming dosomething() won't raise
> KeyError). Now they would b
Martin v. Löwis writes:
> You are missing the rationale of the PEP process. The point is
> *not* documentation. The point of the PEP process is to channel
> and collect discussion, so that the BDFL can make a decision.
> The BDFL is not bound at all to the PEP process.
>
> To document things, we us
Adam Olsen wrote:
> The latter is even the prefered form, since it only invokes a single
> dict lookup:
>
> On 2/16/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
>
>>try:
>>v = d[key]
>>except:
>>v = d[key] = value
>
>
> Obviously this example could be changed to
Martin v. Löwis wrote:
>>I know *I* at least don't like code that mixes up access and
>>modification. Maybe not everyone does (or maybe not everyone thinks of
>>getitem as "access", but that's unlikely). I will assert that it is
>>Pythonic to keep access and modification separate, which is why
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Still -1. It's better, but it violates the principle of encapsulation
> > by mixing how-you-use-it state with what-it-stores state. In doing
> > that it has the potential to break an API documented as accepting a
> >
Adam Olsen wrote:
> You could pass a float in as well. But if the function is documented
> as taking a dict, and the programmer expects a dict.. that now has to
> be changed to "dict without a default". Or they have to code
> defensively since d[key] may or may not raise KeyError, so they must
>
Ian Bicking wrote:
> I know *I* at least don't like code that mixes up access and
> modification. Maybe not everyone does (or maybe not everyone thinks of
> getitem as "access", but that's unlikely). I will assert that it is
> Pythonic to keep access and modification separate, which is why met
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Such are the joys of writing polymorphic code. I don't really see how
> > you can avoid this kind of confusion -- I could have given you some
> > other mapping object that does weird stuff.
>
> You could pass a float in as well. But if the func
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's also makes it harder to read code. You may expect d[key] to
> > raise an exception, but it won't because of a single line up several
> > pages (or in another file entierly!)
>
> Suc
Guido van Rossum wrote:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise exceptions -- so what to do if
Guido van Rossum wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
>>It's also makes it harder to read code. You may expect d[key] to
>>raise an exception, but it won't because of a single line up several
>>pages (or in another file entierly!)
>
>
> Such are the joys of writing polym
On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > d = {}
> > d.default_factory = set
> > ...
> > d[key].add(value)
>
> Another option would be:
>
>d = {}
>d.default_factory = set
>d.get_default(key).add(value)
>
> Unlike .setdefault, this would use a facto
Adam Olsen wrote:
> Still -1. It's better, but it violates the principle of encapsulation
> by mixing how-you-use-it state with what-it-stores state. In doing
> that it has the potential to break an API documented as accepting a
> dict. Code that expects d[key] to raise an exception (and catches
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> It's also makes it harder to read code. You may expect d[key] to
> raise an exception, but it won't because of a single line up several
> pages (or in another file entierly!)
Such are the joys of writing polymorphic code. I don't really see how
Fuzzyman wrote:
>>Also, I think has_key/in should return True if there is a default.
>>
>>
>>
> And exactly what use would it then be ?
Code that checks
if d.has_key(k):
print d[k]
would work correctly. IOW, you could use a dictionary with a default
key just as if it were a normal dictionary
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - There's a fundamental difference between associating the default
> value with the dict object, and associating it with the call. So
> proposals to invent a better name/signature for setdefault() don't
> compete.
That's a feature, not a bu
On Fri, Feb 17, 2006, Guido van Rossum wrote:
>
> But the default implementation is designed so that we can write
>
> d = {}
> d.default_factory = list
+1
I actually like the fact that you're forced to use a separate statement
for setting the default_factory. From my POV, this can go into 2.5.
Guido van Rossum wrote:
> d = {}
> d.default_factory = set
> ...
> d[key].add(value)
Another option would be:
d = {}
d.default_factory = set
d.get_default(key).add(value)
Unlike .setdefault, this would use a factory associated with the
dictionary, and no default value would get passed
Guido van Rossum wrote:
> On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Ahem, I'm still looking for ways to 'overtake' the dict to implement
>> weird and fancy things. Can on_missing be overridden in subclasses (writing
>> the subclass in C would not be a problem)?
>
> Why ahem?
>
> Th
On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Ahem, I'm still looking for ways to 'overtake' the dict to implement
> weird and fancy things. Can on_missing be overridden in subclasses (writing
> the subclass in C would not be a problem)?
Why ahem?
The answer is yes.
--
--Guido van Ross
[cc to py-dev again]
Guido van Rossum wrote:
> On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> So here's a new proposal.
>>>
>>> Let's add a generic missing-key handling method to the dict class, as
>>> well as a default_factory slot initialized to None. The imp
Guido van Rossum wrote:
> So here's a new proposal.
>
> Let's add a generic missing-key handling method to the dict class, as
> well as a default_factory slot initialized to None. The implementation
> is like this (but in C):
>
> def on_missing(self, key):
> if self.default_factory is not None:
On 2/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > A bunch of Googlers were discussing the best way of doing the
>...
> Wow, what a great discussion! As you'll recall, I had also mentioned
> the "callable factory" as a live possib
On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> A bunch of Googlers were discussing the best way of doing the
...
Wow, what a great discussion! As you'll recall, I had also mentioned
the "callable factory" as a live possibility, and there seems to be a
strong sentiment in favor of tha
On Friday 17 February 2006 14:09, Guido van Rossum wrote:
> So here's a new proposal.
I like the version you came up with. It has sufficient functionality to make
it easy to use, and enough flexibility to be useful in more specialized
cases. I'm quite certain it would handle all the cases I'v
On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Over lunch with Alex Martelli, he proposed that a subclass of dict
> with this behavior (but implemented in C) would be a good addition to
> the language. It looks like it wouldn't be hard to implement. It could
> be a builtin named defaultd
On Fri, 17 Feb 2006 08:09:23 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Guido van Rossum wrote:
>> Feedback?
>
>I would like this to be part of the standard dictionary type,
>rather than being a subtype.
>
>d.setdefault([]) (one argument) should install a defaul
>> Also, I think has_key/in should return True if there is a default.
Fredrik> and keys should return all possible key values!
I think keys() and in should reflect reality. Only when you do something
like
x = d['nonexistent']
or
x = d.get('nonexistent')
should the default va
Terry Reedy wrote:
> > I'd say we let the BDFL roam free.
>
> PEPs are useful for question-answering purposes even after approval. The
> design phase can be cut short by simply posting the approved design doc.
not for trivialities. it'll take Guido more time to write a PEP than to
implement the
Raymond Hettinger wrote:
>>>Over lunch with Alex Martelli, he proposed that a subclass of dict
>>>with this behavior (but implemented in C) would be a good addition to
>>>the language
>
>
> I would like to add something like this to the collections module, but a PEP
> is
> probably needed to de
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Raymond Hettinger wrote:
>
>> I would like to add something like this to the collections module, but a
>> PEP is
>> probably needed to deal with issues like:
>
> frankly, now that Guido is working 50% on Python, do we
+1It's about time!- COn 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
A bunch of Googlers were discussing the best way of doing thefollowing (a common idiom when maintaining a dict of lists of valuesrelating to a key, sometimes called a multimap): if key not in d: d[key] = []
d[key].appen
On Thu, Feb 16, 2006 at 01:11:49PM -0800, Guido van Rossum wrote:
[snip]
> Google has an internal data type called a DefaultDict which gets
> passed a default value upon construction. Its __getitem__ method,
> instead of raising KeyError, inserts a shallow copy (!) of the given
> default value into
[EMAIL PROTECTED] wrote:
> Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> Guido> dict with this behavior (but implemented in C) would be a good
> Guido> addition to the language.
>
> Instead, why not define setdefault() the way it should have been done in the
>
Fredrik Lundh wrote:
> Nick Coghlan wrote:
>
>> Using Guido's original example:
>>
>> d.get(key, [], True).append(value)
>
> hmm. are you sure you didn't just reinvent setdefault ?
I'm reasonably sure I copied it on purpose, only with a name that isn't 100%
misleading as to what it does ;)
Guido> Over lunch with Alex Martelli, he proposed that a subclass of
Guido> dict with this behavior (but implemented in C) would be a good
Guido> addition to the language.
Instead, why not define setdefault() the way it should have been done in the
first place? When you create a dict
Nick Coghlan wrote:
> Using Guido's original example:
>
> d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
Adam Olsen wrote:
>> Over lunch with Alex Martelli, he proposed that a subclass of dict
>> with this behavior (but implemented in C) would be a good addition to
>> the language. It looks like it wouldn't be hard to implement. It could
>> be a builtin named defaultdict. The first, required, argument
Phillip J. Eby wrote:
> At 10:10 AM 02/17/2006 +0100, Georg Brandl wrote:
>> Guido van Rossum wrote:
>>
>>> d = DefaultDict([])
>>>
>>> can be written as simply
>>>
>>> d[key].append(value)
>>> Feedback?
>> Probably a good idea, has been proposed multiple times on clpy.
>> One good thing would
On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> A bunch of Googlers were discussing the best way of doing the
> following (a common idiom when maintaining a dict of lists of values
> relating to a key, sometimes called a multimap):
>
> if key not in d: d[key] = []
> d[key].append(valu
Fredrik Lundh wrote:
> Raymond Hettinger wrote:
>
>> I would like to add something like this to the collections module, but a PEP
>> is
>> probably needed to deal with issues like:
>
> frankly, now that Guido is working 50% on Python, do we really have to use
> the full PEP process also for simp
Raymond Hettinger wrote:
> I would like to add something like this to the collections module, but a PEP
> is
> probably needed to deal with issues like:
frankly, now that Guido is working 50% on Python, do we really have to use
the full PEP process also for simple things like this?
I'd say we l
At 10:10 AM 02/17/2006 +0100, Georg Brandl wrote:
>Guido van Rossum wrote:
>
> > d = DefaultDict([])
> >
> > can be written as simply
> >
> > d[key].append(value)
>
> > Feedback?
>
>Probably a good idea, has been proposed multiple times on clpy.
>One good thing would be to be able to specify ei
> My conclusion is that setdefault() is a failure -- it was a
> well-intentioned construct, but doesn't actually create more readable
> code.
It was an across the board failure: naming, clarity, efficiency.
Can we agree to slate dict.setdefault() to disappear in Py3.0?
Raymond
_
Martin v. Löwis wrote:
> Also, I think has_key/in should return True if there is a default.
and keys should return all possible key values!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
1 - 100 of 115 matches
Mail list logo
