lambda

[Egor Bolonev]

why functions created with lambda forms cannot contain statements?

how to get unnamed function with statements?

[Nick Coghlan]

David Eppstein wrote:

Yes, and what should the following do?

lst1 = [1]
lst2 = [2]
dct = {lst1: "1", lst2: "2"}
lst2[0]=1
lst1[0]=2
print dct[[1]]
print dct[[2]]

Provide yet another example for why mutable keys are almost guaranteed to result
in suprising semantics :)

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Nick Coghlan]

Antoon Pardon wrote:

As you said yourself, people use shortcuts when they express themselves.
With 'mutable key' I mean a mutable object that is used as a key.
That doesn't contradict that the key itself can't change because
it is inaccessible.
Yeah - this was the point of terminology that was getting confused, I think. And
your interpretation was closer to the strict sense of the words.

Well, the Zen of Python states "In the face of ambiguity, refuse the temptation
to guess".

But python does guess in the case of the value. If I want to establish a
relationship between "foo" and [3, 5, 8] then I can be in big trouble
if that list gets mutated in something else.

However, the actual promise a Python dict makes is that it maps from keys by
value to values by identity.

That is, "k1 == k2" implies "d[k1] is d[k2]". An identity test on mutable
objects is entirely unambiguous (hence they can be values), but comparison is
not (hence they cannot be keys). Restricting keys to immutable objects
eliminates the ambiguity. Copying keys would also prevent mutation and eliminate
the ambiguity. The restriction approach is a *definite* performance enhancement
over the copying approach, though (this is probably the origin of the mantra
"the restriction to mutable keys is a performance enhancement"). The resulting
semantics of the restriction to immutable objects are also significantly less
surprising than those of the copying approach.

An identity dict would make the promise that "k1 is k2" implies "d[k1] is
d[k2]". In this case, the mutability of the key is irrelevant, so the behaviour
is unambiguous without any additional restrictions.
But they don't have to be immutable within the dictionary itself, that
is just an implementation detail. The only thing that matters is that
the dictionary can reproduce the relationship. How that is done is
immaterial.
Given the Python interpreter's current definition of "immutable" as "defines
__hash__", it's a little hard to have an unhashable object as a key :)

In short, sane hash tables require immutable keys, and how mutable keys acquire
the requisite immutability is going to be application dependent.

No they don't, that is just the most easy implementation. If some
implementation would constantly change the internal objects but
consulting the dictionary wouldn't show any different effect then
that would be fine too. And even in this case a mutation
from the outside would probably cause havoc because it would ruin
the sanity of the internal structure.

If you insist: s/immutable/effectively immutable/

And no data type can be expected to tolerate having their invariants violated by
external code messing with internal data structures.

Provision of a safe_dict or identity_dict would merely allow a programmer to
state their intent at the time the container is created, rather than having to
state it whenever keys are generated or referenced.

Well that would be a good thing IMO.

True - I'm not sure how that 'merely' snuck in there :)
Good enough in any case for me to
spend some time analyzing the requirements. Whether I'll actually
implement something depends on how much time I have and how often I
need it.

My preference is for the identity dict - its performance would actually be
*better* than that of a standard dict in the domains where it applies
(annotation and classification of objects are the two main uses I can see for
such a data structure). This aligns quite well with the stated goal of the
collections module (providing data structures that are less general purpose than
the standard builtins, but deliver better performance for their particular use
cases)

Regards,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Nick Coghlan]

Antoon Pardon wrote:

Interesting idea. But I think you are wrong when you say that two lists
that compare equal at the time they are frozen, will get the same
dictionary entry. The problem is an object must compare equal to
the key in the dictionary to get at the same entry. So if you freeze
a list and its copy but then mutate them differently, they no longer
are equal and so wont get you at the same entry.

The trick is that the result of the freezing operation is cached until such time
as you explicitly unfreeze the object.

Output:

x: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
y: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Write via x, read via y: Hi there!
x: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
y: [0, 1, 2, 3, 4, 5, 6, 7, 8]
Read via mutated x: Hi there!
Read via mutated y: Hi there!
x: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
y: [0, 1, 2, 3, 4, 5, 6, 7, 8]
Found unfrozen x: False
Found unfrozen y: False
Produced by:

class mylist(list):
def __init__(self, arg):
super(mylist, self).__init__(arg)
self._tuple = None
def frozen(self):
if self._tuple is None:
self._tuple = tuple(self)
return self._tuple
def unfreeze(self):
self._tuple = None

x = mylist(range(10))
y = mylist(range(10))
dct = {}
dct[x.frozen()] = "Hi there!"
print "x:", x
print "y:", y
print "Write via x, read via y:", dct[y.frozen()]
x.append(10)
del y[-1]
print "x:", x
print "y:", y
print "Read via mutated x:", dct[x.frozen()]
print "Read via mutated y:", dct[y.frozen()]
x.unfreeze()
y.unfreeze()
print "x:", x
print "y:", y
print "Found unfrozen x:", x.frozen() in dct
print "Found unfrozen y:", y.frozen() in dct

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Antoon Pardon]

Op 2005-01-20, Nick Coghlan schreef <nc******@iinet.net.au>:

Antoon Pardon wrote:

Interesting idea. But I think you are wrong when you say that two lists
that compare equal at the time they are frozen, will get the same
dictionary entry. The problem is an object must compare equal to
the key in the dictionary to get at the same entry. So if you freeze
a list and its copy but then mutate them differently, they no longer
are equal and so wont get you at the same entry.

The trick is that the result of the freezing operation is cached until such time
as you explicitly unfreeze the object.

I missed that you would use it with the idiom: dct[x.frozen()]

I have two problems with this approach.

1) It doesn't work when you get your keys via the keys/items
methods.

2) This is rather minor, but a user could still unfreeze
untimely

--
Antoon Pardon

[Nick Coghlan]

Antoon Pardon wrote:

I missed that you would use it with the idiom: dct[x.frozen()]
The list itself isn't hashable with this approach, so you don't have much
choice. I wasn't particularly clear about that point, though.
I have two problems with this approach.

1) It doesn't work when you get your keys via the keys/items
methods.
True - the frozen object has no link back to the original object. That could be
added though (by returning a tuple subtype with the extra attribute)
2) This is rather minor, but a user could still unfreeze
untimely

True - doing that is less likely than mutating a hashable list though :)

I'm just noting this as a way to avoid copying data more than once when storing
immutable copies of mutable data in a dictionary. You're quite right that there
isn't a really clean idiom for doing that in Python (aside from moving to a
different data structure that works natively as a dict key, naturally).

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Antoon Pardon]

Op 2005-01-20, Nick Coghlan schreef <nc******@iinet.net.au>:

Antoon Pardon wrote:

I missed that you would use it with the idiom: dct[x.frozen()]

The list itself isn't hashable with this approach, so you don't have much
choice. I wasn't particularly clear about that point, though.

I have two problems with this approach.

1) It doesn't work when you get your keys via the keys/items
methods.

True - the frozen object has no link back to the original object. That could be
added though (by returning a tuple subtype with the extra attribute)

2) This is rather minor, but a user could still unfreeze
untimely

True - doing that is less likely than mutating a hashable list though :)

I'm just noting this as a way to avoid copying data more than once when storing
immutable copies of mutable data in a dictionary. You're quite right that there
isn't a really clean idiom for doing that in Python (aside from moving to a
different data structure that works natively as a dict key, naturally).

The problem here is IMO is the, we are all consenting adults (which we
are not but I wont start on this now), approach.

I have been thinking a bit in your freeze direction, but more thorough.
The idea i had was that freeze would replace all mutating methods
with methods that would throw an exception. a thaw method would inverse
the proces. It would then be the responsibilty of the dictionary to
freeze an object on entry and thaw it when removed. However this
wouldn't work with ordinary python objects, since there is no easy way
to have readonly or private variables.

--
Antoon Pardon

[Bengt Richter]

On 20 Jan 2005 14:07:57 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-01-20, Nick Coghlan schreef <nc******@iinet.net.au>:

Antoon Pardon wrote:

I missed that you would use it with the idiom: dct[x.frozen()]

The list itself isn't hashable with this approach, so you don't have much
choice. I wasn't particularly clear about that point, though.

I have two problems with this approach.

1) It doesn't work when you get your keys via the keys/items
methods.

True - the frozen object has no link back to the original object. That could be
added though (by returning a tuple subtype with the extra attribute)

2) This is rather minor, but a user could still unfreeze
untimely

True - doing that is less likely than mutating a hashable list though :)

I'm just noting this as a way to avoid copying data more than once when storing
immutable copies of mutable data in a dictionary. You're quite right that there
isn't a really clean idiom for doing that in Python (aside from moving to a
different data structure that works natively as a dict key, naturally).

The problem here is IMO is the, we are all consenting adults (which we
are not but I wont start on this now), approach.

I have been thinking a bit in your freeze direction, but more thorough.
The idea i had was that freeze would replace all mutating methods
with methods that would throw an exception. a thaw method would inverse
the proces. It would then be the responsibilty of the dictionary to
freeze an object on entry and thaw it when removed. However this
wouldn't work with ordinary python objects, since there is no easy way
to have readonly or private variables.

Would you like a dictionary that acts as you want and takes care of all
problems internally, and accepts keys and values of any type without wrapping
or other modification -- or do you want a wrapper that can make any object
suitable for use as key or value in python's curent definition of dict?

Just DYFR please. You still haven't you know ;-)

Regards,
Bengt Richter

[Antoon Pardon]

Op 2005-01-21, Bengt Richter schreef <bo**@oz.net>:

On 20 Jan 2005 14:07:57 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Would you like a dictionary that acts as you want and takes care of all
problems internally, and accepts keys and values of any type without wrapping
or other modification -- or do you want a wrapper that can make any object
suitable for use as key or value in python's curent definition of dict?

Just DYFR please. You still haven't you know ;-)

My feeling is that I'm hungry and would like to eat and you ask whether
my requirements are a sandwhich or a bowl of soup. :-)

The real requirement IMO is that any attempt to mutate an object wont
result in a mutated key. Both proposals seem to solve that. The second
is at the moment for me the most interesting to discuss, since it is
a new approach to me, and most likely to learn me something new.

--
Antoon Pardon