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 was
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 process.
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 dictionary,
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 like
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
___
Python-Dev
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
provided an
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
This is
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 same
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
have
to
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 a
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
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 think
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 operations
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 circular
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 you end up
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 *not*
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 can argue that
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
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)
Unlike .setdefault, this would use
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 exceptions
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 the
first
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 and
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 similar
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 case of two
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 as a
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 subset
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
[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
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
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)
Another option would be:
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
should be
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
be a
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 behaviour
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
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 raise an
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 opposite
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 mean if
[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.
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 modifiable
[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 in
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
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 either a default value
or a factory function.
While at it, other
Guido van Rossum 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(value)
An alternative way to spell
On Thu, 16 Feb 2006 13:11:49 -0800, 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] = []
Thomas Heller wrote:
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify either a default value
or a factory function.
While at it, other interesting dict subclasses could be:
* sorteddict, practically reinvented by every larger
On 2/17/06, Raymond Hettinger [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
I would like to add something like this to the collections module,
+1
but a PEP is
Martin v. Lwis 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
Guido van Rossum 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(value)
/.../
Feedback?
+1. check it
On Thu, Feb 16, 2006 at 01:11:49PM -0800, Guido van Rossum 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
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!
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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
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 either a default
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 simple things
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(value)
An
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 be to be able to specify
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 to the
Nick Coghlan wrote:
Using Guido's original example:
d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
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
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 ;)
I think
[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
first
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
+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] = []
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 really have
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 deal with
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
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
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 defaultdict.
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
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 that;
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 possibility, and
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:
[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 implementation
is
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 Rossum
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 in.
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.
(I
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 bug. :)
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 - which
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
you
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, 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 factory associated with
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 polymorphic code.
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
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!)
Such are the
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 function is
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
avoid
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
dict. Code
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 methods
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 use
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 use (or
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 behave
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].
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 modifying
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
defensively since
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() calls
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 your
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 we cut off
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*.
More
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:
dosomethingelse()
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?
class
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 think
'd
1 - 100 of 102 matches
Mail list logo
