Re: Pre-PEP: Dictionary accumulator methods - typing initialising

2005-03-20 Thread Kay Schluehr 
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 override
the
 action to be taken when accessing a non-existent key?

d.defaultValue(0)

 and the accumulation becomes:

d[key] += 1

 and:

d.defaultValue(function=list)

 would allow a safe:

   d[key].extend(values)

+0

The best suggestion up to now. But i find this premature because it
addresses only a special aspect of typing issues which should be
disussed together with Guidos type guard proposals in a broader
context. Besides this the suggestion though feeling pythonic is still
uneven.

Why do You set

d.defaultValue(0)
d.defaultValue(function=list)

but not

d.defaultValue(0)
d.defaultValue([])

?

And why not dict(type=int), dict(type=list) instead where default
values are instantiated during object creation? A consistent pythonic
handling of all types should be envisioned not some ad hoc solutions
that go deprecated two Python releases later.

Regards Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pre-PEP: Dictionary accumulator methods - typing initialising

2005-03-20 Thread Matteo Dell'Amico 
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* default values. In other words, given:

class DefDict(dict):
def __init__(self, default):
self.default = default
def __getitem__(self, item):
try:
return dict.__getitem__(self, item)
except KeyError:
return self.default
you'll get
In [12]: d = DefDict([])
In [13]: d[42].extend(['foo'])
In [14]: d.default
Out[14]: ['foo']
In [15]: d[10].extend(['bar'])
In [16]: d.default
Out[16]: ['foo', 'bar']
In [17]: d[10]
Out[17]: ['foo', 'bar']
In [18]: d[10] is d.default
Out[18]: True
and this isn't what you really wanted.
By the way, to really work, I think that Duncan's proposal should create 
new objects when you try to access them, and to me it seems a bit 
counterintuitive. Nevertheless, I'm +0 on it.

And why not dict(type=int), dict(type=list) instead where default
values are instantiated during object creation? A consistent pythonic
handling of all types should be envisioned not some ad hoc solutions
that go deprecated two Python releases later.
I don't really understand you. What should 'type' return? A callable 
that returns a new default value? That's exactly what Duncan proposed 
with the function keyword argument.

--
Ciao,
Matteo
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pre-PEP: Dictionary accumulator methods - typing initialising

2005-03-20 Thread Kay Schluehr 
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 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 be called. This is all equivalent and it
does not matter ( except for performance reasons ) which way to go as
long only one is selected.

[...]

 By the way, to really work, I think that Duncan's proposal should
create
 new objects when you try to access them, and to me it seems a bit
 counterintuitive.

If the dict has a fixed semantics by applying defaultValue() and it
returns defaults instead of exceptions whenever a key is missing i.e.
behavioural invariance the client of the dict has nothing to worry
about, hasn't he?


  And why not dict(type=int), dict(type=list) instead where default
  values are instantiated during object creation? A consistent
pythonic
  handling of all types should be envisioned not some ad hoc
solutions
  that go deprecated two Python releases later.

 I don't really understand you. What should 'type' return?
 A callable
 that returns a new default value? That's exactly what Duncan proposed

 with the function keyword argument.

I suspect the proposal really makes sense only if the dict-values are
of the same type. Filling it with strings, custom objects and other
stuff and receiving 0 or [] or '' if a key is missing would be a
surprise - at least for me. Instantiating dict the way I proposed
indicates type-guards! This is the reason why I want to delay this
issue and discuss it in a broader context. But I'm also undecided.
Guidos Python-3000 musings are in danger to become vaporware. Now is
better then never... Therefore +0.

Regards Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pre-PEP: Dictionary accumulator methods - typing initialising

2005-03-20 Thread Matteo Dell'Amico 
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 be called. This is all equivalent and it
does not matter ( except for performance reasons ) which way to go as
long only one is selected.
I don't like it very much... it seems too implicit to be pythonic. Also, 
it won't work with non-copyable objects, and type(42)() = 0, and getting 
0 when the default is 42 looks very strange. I prefer the explicit give 
me a callable approach.

If the dict has a fixed semantics by applying defaultValue() and it
returns defaults instead of exceptions whenever a key is missing i.e.
behavioural invariance the client of the dict has nothing to worry
about, hasn't he?
For idioms like d[foo].append('blah') to work properly, you'd have to 
set the default value every time you access a variable. It can be really 
strange to fill up memory only by apparently accessing values.

I suspect the proposal really makes sense only if the dict-values are
of the same type. Filling it with strings, custom objects and other
stuff and receiving 0 or [] or '' if a key is missing would be a
surprise - at least for me. Instantiating dict the way I proposed
indicates type-guards! This is the reason why I want to delay this
issue and discuss it in a broader context. But I'm also undecided.
Guidos Python-3000 musings are in danger to become vaporware. Now is
better then never... Therefore +0.
Having duck-typing, we can have things that have common interface but no 
common type. For instance, iterables. I can imagine a list of iterables 
of different types, and a default value of maybe [] or set([]).

--
Ciao,
Matteo
--
http://mail.python.org/mailman/listinfo/python-list