Greg Ewing wrote:
Fredrik Lundh wrote:
fwiw, the first google hit for "autodict" appears to be part of someone's
link farm
At this website we have assistance with autodict. In addition to
information for autodict we also have the best web sites concerning
dictionary,
Fredrik Lundh wrote:
> fwiw, the first google hit for "autodict" appears to be part of someone's
> link farm
>
> At this website we have assistance with autodict. In addition to
> information for autodict we also have the best web sites concerning
> dictionary, non profit and new york
On Feb 22, 2006, at 7:21 AM, Raymond Hettinger wrote:
...
> I'm somewhat happy with the patch as it stands now. The only part
> that needs serious rethinking is putting on_missing() in regular
> dicts. See my other email on that subject.
What if we named it _on_missing? Hook methods int
[Alex]
> I'd love to remove setdefault in 3.0 -- but I don't think it can be done
> before that: default_factory won't cover the occasional use cases where
> setdefault is called with different defaults at different locations, and,
> rare as those cases may be, any 2.* should not break any e
Greg Ewing wrote:
Fuzzyman wrote:
cfg = ConfigObj(newfilename)
cfg['key'] = 'value'
cfg['key2'] = ['value1', 'value2', 'value3']
cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenien
Fuzzyman wrote:
> cfg = ConfigObj(newfilename)
> cfg['key'] = 'value'
> cfg['key2'] = ['value1', 'value2', 'value3']
> cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenience, then I'd be inclined to require a
Raymond Hettinger wrote:
> Like "autodict" could mean anything.
fwiw, the first google hit for "autodict" appears to be part of someone's
link farm
At this website we have assistance with autodict. In addition to
information for autodict we also have the best web sites concerning
dic
Greg Ewing wrote:
Fuzzyman wrote:
I've had problems in code that needs to treat strings, lists and
dictionaries differently (assigning values to a container where all
three need different handling) and telling the difference but allowing
duck typing is *problematic*.
Yo
Steve Holden wrote:
> Given that the default entries behind the non-existent keys don't
> actually exist, something like "virtual_dict" might be appropriate.
No, that would suggest to me something like
a wrapper object that delegates most of the
mapping protocol to something else. That's
even le
Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>
>>Like "autodict" could mean anything.
>
>
> Everything is meaningless until you know something
> about it. If you'd never seen Python before,
> would you know what 'dict' meant?
>
> If I were seeing "defaultdict" for the first time,
> I would n
Raymond Hettinger wrote:
> Like "autodict" could mean anything.
Everything is meaningless until you know something
about it. If you'd never seen Python before,
would you know what 'dict' meant?
If I were seeing "defaultdict" for the first time,
I would need to look up the docs before I was
confi
> Alex Martelli wrote:
>
>> If we call the type autodict, then having the factory attribute named
>> autofactory seems to fit.
>
> Or just 'factory', since it's the only kind of factory
> the object is going to have.
Gack, no. You guys are drifting towards complete ambiguity.
You might as wel
Fuzzyman wrote:
> I've had problems in code that needs to treat strings, lists and
> dictionaries differently (assigning values to a container where all
> three need different handling) and telling the difference but allowing
> duck typing is *problematic*.
You need to rethink your design so that
Alex Martelli wrote:
> If we call the type autodict, then having the factory attribute named
> autofactory seems to fit.
Or just 'factory', since it's the only kind of factory
the object is going to have.
--
Greg Ewing, Computer Science Dept, +--+
Universit
On Tue, 21 Feb 2006, Guido van Rossum wrote:
[...]
> If you're only interested in classifying the three specific built-ins
> you mention, I'd check for the presense of certain attributes:
> hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort")
> -> x is a list; hasattr(x, "update")
Raymond Hettinger wrote:
>>Yes, I now agree. This means that I'm withdrawing proposal A (new
>>method) and championing only B (a subclass that implements
>>__getitem__() calling on_missing() and on_missing() defined in that
>>subclass as before, calling default_factory unless it's None). I don't
>>
Then you will likely be happy with Guido's current version of the patch.
- Original Message -
From: "Crutcher Dunnavant" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Python Dev"
Sent: Monday, February 20, 200
>> > Just one more thing -- have you made a final decision
>> > about the name yet? I'd still prefer something like
>> > 'autodict', because to me 'defaultdict' suggests
>>
>> autodict is shorter and sharper and I prefer it, too: +1
>
> Apart from it somehow hashing to the same place as "autodidact
On Tue, 21 Feb 2006 05:58:52 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>> How about doing it as an expression, empowering ( ;-) the dict just afer
>> creation?
>> E.g., for
>>
>> d = dict()
>> d.default_factory = list
>>
>>
On 2/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
> ...
> > Just one more thing -- have you made a final decision
> > about the name yet? I'd still prefer something like
> > 'autodict', because to me 'defaultdict' suggests
>
> autodict is sh
Guido van Rossum wrote:
>On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
>
>>I've had problems in code that needs to treat strings, lists and
>>dictionaries differently (assigning values to a container where all
>>three need different handling) and telling the difference but allowing
>>duck ty
On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
...
> Just one more thing -- have you made a final decision
> about the name yet? I'd still prefer something like
> 'autodict', because to me 'defaultdict' suggests
autodict is shorter and sharper and I prefer it, too: +1
> etc.) it seems more a
On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
> I've had problems in code that needs to treat strings, lists and
> dictionaries differently (assigning values to a container where all
> three need different handling) and telling the difference but allowing
> duck typing is *problematic*.
Consider
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> How about doing it as an expression, empowering ( ;-) the dict just afer
> creation?
> E.g., for
>
> d = dict()
> d.default_factory = list
>
> you could write
>
> d = dict()**list
Bengt, can you let your overactive imagination res
Greg Ewing wrote:
>Delaney, Timothy (Tim) wrote:
>
>
>
>>However, *because* Python uses duck typing, I tend to feel that
>>subclasses in Python *should* be drop-in replacements.
>>
>>
>
>Duck-typing means that the only reliable way to
>assess whether two types are sufficiently compatible
>fo
Bengt Richter wrote:
> you could write
>
> d = dict()**list
Or alternatively,
ld = dict[list]
i.e. "a dict of lists". In the maximally twisted
form of this idea, the result wouldn't be a dict
but a new *type* of dict, which you would then
instantiate:
d = ld(your_favourite_args_here
Guido van Rossum wrote:
> It's quite tricky to implement a fully
> transparent wrapper that supports all the special
> methods (__setitem__ etc.).
I was thinking the wrapper would only be a means of
filling the dict -- it wouldn't even pretend to
implement the full dict interface. The only metho
Delaney, Timothy (Tim) wrote:
> However, *because* Python uses duck typing, I tend to feel that
> subclasses in Python *should* be drop-in replacements.
Duck-typing means that the only reliable way to
assess whether two types are sufficiently compatible
for some purpose is to consult the document
Raymond Hettinger wrote:
>> - It would be unwise to have a default value that would be called if
>> it was callable: what if I wanted the default to be a class instance
>> that happens to have a _call_ method for unrelated reasons?
>> Callability is an elusive propperty; APIs should not attempt to
On Mon, 20 Feb 2006 11:09:48 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
>
>> [GvR]
>>> I'm not convinced by the argument
>>> that __contains__ should always return True
>>
>> Me either. I cannot think of a more useless behavior or one
[Guido]
> ...
> What's the practical use case for not wanting __contains__() to
> function?
I don't know. I have practical use cases for wanting __contains__()
to function, but there's been no call for those. For an example,
think of any real use ;-)
For example, I often use dicts to represent
On 2/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Have you considered the third alternative that's been
> mentioned -- a wrapper?
I don't like that at all. It's quite tricky to implement a fully
transparent wrapper that supports all the special methods (__setitem__
etc.). It will be slower. And
"Martin v. Löwis" wrote:
> Delaney, Timothy (Tim) wrote:
>> However, *because* Python uses duck typing, I tend to feel that
>> subclasses in Python *should* be drop-in replacements. If it's not a
>> drop-in replacement, then it should probably not subclass, but just
>> use duck typing (probably by
On 2/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [stuff with typos]
Here's the proofread version:
I have a patch ready that implements this. I've assigned it to Raymond
for review. I'm just reusing the same SF patch as before:
http://python.org/sf/1433928 .
One subtlety: for maximal fle
On 2/20/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > [Alex]
> >>> I see d[k]+=1 as a substantial improvement -- conceptually more
> >>> direct, "I've now seen one more k than I had seen before".
> >
> > [Guido]
> >> Yes, I now agree. This means that I'm withdrawing proposal A (new
> >> method)
in two ways:
1) dict.get doesn't work for object dicts or in exec/eval contexts, and
2) dict.get requires me to generate the default value even if I'm not
going to use it, a process which may be expensive.
On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Crutcher Dunnavant ]
> >> There
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote:
> [Alex]
>>> I see d[k]+=1 as a substantial improvement -- conceptually more
>>> direct, "I've now seen one more k than I had seen before".
>
> [Guido]
>> Yes, I now agree. This means that I'm withdrawing proposal A (new
>> method) and champio
[Alex]
>> I see d[k]+=1 as a substantial improvement -- conceptually more
>> direct, "I've now seen one more k than I had seen before".
[Guido]
> Yes, I now agree. This means that I'm withdrawing proposal A (new
> method) and championing only B (a subclass that implements
> __getitem__() calling o
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote:
...
>> - "Yes and it should be the only constructor argument." This is my
...
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass instead of storing a dict
How so? Liskov's pr
Delaney, Timothy (Tim) wrote:
> However, *because* Python uses duck typing, I tend to feel that
> subclasses in Python *should* be drop-in replacements. If it's not a
> drop-in replacement, then it should probably not subclass, but just use
> duck typing (probably by wrapping).
Inheritance is more
Greg Ewing wrote:
> In other words, just because A inherits from B in
> Python isn't meant to imply that an A is a drop-in
> replacement for a B.
Hmm - this is interesting. I'm not arguing Liskov violations or anything
...
However, *because* Python uses duck typing, I tend to feel that
subclasse
Brett Cannon wrote:
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass
I'm not sure we should be too worried about that.
Inheritance in Python has always been more about
implementation than interface, so Liskov doesn't
really apply in
Guido van Rossum wrote:
> I see two alternatives.
Have you considered the third alternative that's been
mentioned -- a wrapper?
The issue of __contains__ etc. could be sidestepped by
not giving the wrapper a __contains__ method at all.
If you want to do an 'in' test you do it on the
underlying d
On 2/20/06, Dan Gass <[EMAIL PROTECTED]> wrote:
> Why not have the factory function take the key being looked up as an
> argument?
This was considered and rejected already.
You can already customize based on the key by overriding on_missing()
[*]. If the factory were to take a key argument, we co
On 2/20/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass instead of storing a dict
> internally (can't remember the name of the design pattern that does
> this). But I think it is good to ha
On 2/20/06, Dan Gass <[EMAIL PROTECTED]> wrote:
> Why not have the factory function take the key being looked up as an
> argument? Seems like there would be uses to customize the default based on
> the key. It also forces you to handle list factory functions and constant
> factory functions (amon
[Steven Bethard]
> * Should default_factory be an argument to the constructor? The three
> answers I see:
>
> - "No." I'm not a big fan of this answer. Since the whole point of
> creating a defaultdict type is to provide a default, requiring two
> statements (the constructor call and the defaul
On 2/20/06, Raymond Hettinger <
[EMAIL PROTECTED]> wrote:
An alternative is to have two possible attributes: d.default_factory = listor d.default_value = 0with an exception being raised when both are defined (the test is done when theattribute is created, not when the lookup is performed).
Why n
On 2/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I wrote:
> ># I want to do ``dd[item] += 1``
>
> Guido van Rossum wrote:
> > You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> > is perfectly fine there and hard to improve upon.
>
> Alex Martelli wrote:
> > I see d[
I wrote:
># I want to do ``dd[item] += 1``
Guido van Rossum wrote:
> You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
> I see d[k]+=1 as a substantial improvement -- conceptually more
> direct, "I'v
Guido van Rossum wrote:
> Why are you so keen on using a dictionary to share data between
> threads that may both modify it? IMO this is asking for trouble --
> the advice about sharing data between threads is always to use the
> Queue module.
I use them often for a shared caches. But yeah, it's
[Crutcher Dunnavant ]
>> There are many times that I want d[key] to give me a value even when
>> it isn't defined, but that doesn't always mean I want to _save_ that
>> value in the dict.
How does that differ from the existing dict.get method?
Raymond
___
On 2/20/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
> ...
> > You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> > is perfectly fine there and hard to improve upon.
>
> I see d[k]+=1 as a substantial improvement --
On 2/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Also, is default_factory=list threadsafe in the same way .setdefault is?
> That is, you can safely do this from multiple threads:
>
>d.setdefault(key, []).append(value)
>
> I believe this is safe with very few caveats -- setdefault itself i
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
> You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, "I've now seen one more k than I had
On 2/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Would it be deprecated in 2.*, or start deprecating in 3.0?
3.0 will have no backwards compatibility allowances. Whenever someone
says "remove this in 3.0" they mean exactly that. There will be too
many incompatibilities in 3.0 to be bothered wi
Steven Bethard wrote:
>>Alternative A: add a new method to the dict type with the semantics of
>>__getattr__ from the last proposal, using default_factory if not None
>>(except on_missing is inlined).
>
>
> I'm not certain I understood this right but (after
> s/__getattr__/__getitem__) this seems
Alex Martelli wrote:
>>I prefer this approach over subclassing. The mental load from an
>>additional
>>method is less than the load from a separate type (even a
>>subclass). Also,
>>avoidance of invariant issues is a big plus. Besides, if this allows
>>setdefault() to be deprecated, it beco
I'm thinking something mutch closer to this (note default_factory gets the key):
def on_missing(self, key):
if self.default_factory is not None:
value = self.default_factory(key)
if self.on_missing_define_key:
self[key] = value
return value
raise KeyError(key)
On 2/20/06, Cr
Sorry to chime in so late, but why are we setting a value when the key
isn't defined?
It seems there are many situations where you want:
a) default values, and
b) the ability to determine if a value was defined.
There are many times that I want d[key] to give me a value even when
it isn't def
On 2/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Alternative A: add a new method to the dict type with the semantics of
> > [__getitem__] from the last proposal, using default_factory if not None
> > (except on_missing is inlined).
>
> I'm not certain I understood
Guido van Rossum wrote:
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to sug
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
> [GvR]
>> I'm not convinced by the argument
>> that __contains__ should always return True
>
> Me either. I cannot think of a more useless behavior or one more
> likely to have
> unexpected consequences. Besides, as Josiah pointed out, it
On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> > Alternative A: add a new method to the dict type with the semantics of
> > __getattr__ from the last proposal
>
> Did you mean __getitem__?
Yes, sorry, I meant __getitem__.
--
--Guido van Rossum (home page: http://www.python.org
On Mon, 20 Feb 2006 05:41:43 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>I'm withdrawing the last proposal. I'm not convinced by the argument
>that __contains__ should always return True (perhaps it should also
>insert the value?), nor by the complaint that a holy invariant would
>be vi
[GvR]
> I'm not convinced by the argument
> that __contains__ should always return True
Me either. I cannot think of a more useless behavior or one more likely to
have
unexpected consequences. Besides, as Josiah pointed out, it is much easier for
a subclass override to substitute always True
On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
...
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined). This avoids the discussion about
> broken invariants, but o
I'm withdrawing the last proposal. I'm not convinced by the argument
that __contains__ should always return True (perhaps it should also
insert the value?), nor by the complaint that a holy invariant would
be violated (so what?).
But the amount of discussion and the number of different viewpoints
68 matches
Mail list logo
