Freezing

[bearophileHUGS@lycos.com]

Most of my ideas seem usless or stupid, but I think expressing them
here doesn't harm much.
This is an idea for Py 3.0, because it's not backward compatible.

Dicts and sets require immutable keys, like tuples or frozensets, but
to me they look like a duplication. So the idea is to remove tuples and
frozensets (and replace the few other uses of tuples with lists, like
the % interpolation), and to add a freeze operation, to freeze lists,
sets and dicts (etc), so they can be used as keys.

The syntax to do this maybe can be a builtin freeze(data) function, or
a |data|, or something different.
This freezing can be shallow or deep (recursive).

Example:
s = |set(1, 3, 5)|
d1 = |{s:1}|
d2 = {d1:1}

The "|" binary xor can become written "XOR", like the AND, OR, NOT.
The &^~ so become free to be used for other purposes, operator
overloading, etc (silly example: ^ for pow instead of **, so the
**identifier is used only for keyword arguments, etc).

Bye,
bearophile

[bearophileHUGS@lycos.com]

Re: Freezing

The first line of that example has to be:

s = |set([1, 3, 5])|

But I don't know/remember why set() can't accept many values like
max/min:

max([1,2,5])
max((1,2,5))
max(1,2,3)

Bye,
bearophile

[Xavier Morel]

Re: Freezing

bearophileHUGS@ lycos.com wrote:[color=blue]
> The first line of that example has to be:
>
> s = |set([1, 3, 5])|
>
> But I don't know/remember why set() can't accept many values like
> max/min:
>
> max([1,2,5])
> max((1,2,5))
> max(1,2,3)
>
> Bye,
> bearophile
>[/color]

How about just providing a freeze method on `object` (since everything
will inherit from object) that can freeze the object?

In fact the freeze protocol could provide 2 methods: freeze and frozen,
the former would freeze the object in place (e.g. freeze the object it's
applied to) while the later would return a frozen copy of the object
it's applied to.

That way, it could even be used as a const-like parameter to a function
(with frozen)

Examples:[color=blue][color=green][color=darkred]
>>> l = [0, 1, 2, 3]
>>> l.append(5)
>>> l[/color][/color][/color]
[0, 1, 2, 3, 5][color=blue][color=green][color=darkred]
>>> l.frozen()[/color][/color][/color]
[0, 1, 2, 3, 5][color=blue][color=green][color=darkred]
>>> fl = l.frozen()
>>> l.append(7)
>>> l[/color][/color][/color]
[0, 1, 2, 3, 5, 7][color=blue][color=green][color=darkred]
>>> fl.append(7)[/color][/color][/color]
Traceback (most recent call last):
....
WhateverError: frozen 'list' object cannot modified[color=blue][color=green][color=darkred]
>>> fl[/color][/color][/color]
[0, 1, 2, 3, 5][color=blue][color=green][color=darkred]
>>> l.freeze()
>>> l[/color][/color][/color]
[0, 1, 2, 3, 5, 7][color=blue][color=green][color=darkred]
>>> l.append(9)[/color][/color][/color]
Traceback (most recent call last):
....
WhateverError: frozen 'list' object cannot modified

One could even dream of a melt/molten method pair that'd behave at the
opposite of the freeze/frozen pair (to have the ability to "unfreeze" an
object if needed)

No new keyword, no new token, no new structure, no new builtin, same
functionalities .

[Raymond Hettinger]

Re: Freezing

bearophileHUGS@ lycos.com wrote:[color=blue]
> add a freeze operation, to freeze lists,
> sets and dicts (etc), so they can be used as keys.[/color]

I'm curious whether you've had an actual use for dictionaries as keys.

Likewise, how about frozensets? Have you had occasion to use them as
keys? They were created to support sets of sets, yet even that doesn't
come-up often.

There seems to be a disease going around and those infected become
irresistibly fascinated with freezing. After developing a resistance
to practical applications, the infection becomes feverish resulting in
delirious proposals to change the entire language to accommodate the
freezing (these have included eliminating tuples, making strings
mutable, recursive freezing, and adding a __freeze__ protocol to all
containers).

For some reason, it sounds charming to be able to use a dictionary as a
key, yet it loses its grace when phrased in terms of what can already
be done:

k = frozenset(mydic t.iteritems())
somedict[k] = someval

AFAICT, no one seems to write code like this. So why build a mechanism
to automate a process that no one uses?

Also note that Guido has said over and over that tuples are NOT
frozenlists. Even with a mechanism to freeze lists, tuples won't go
away.

One other nit. The term "freezing" inaccurately suggests an in-place
operation; however, the PythonWay(tm) is to create new objects (i.e.
given a mutable set s, the result of frozenset(s) is a new container).
The non-PythonWay is to have state flag indicating frozenness and have
that flag disable mutating methods while enabling a __hash__ method.


Raymond

[Mike Meyer]

Re: Freezing

Xavier Morel <xavier.morel@m asklinn.net> writes:[color=blue]
>bearophileHUGS @lycos.com wrote:[color=green]
>> Dicts and sets require immutable keys, like tuples or frozensets, but
>> to me they look like a duplication. So the idea is to remove tuples and
>> frozensets (and replace the few other uses of tuples with lists, like
>> the % interpolation), and to add a freeze operation, to freeze lists,
>> sets and dicts (etc), so they can be used as keys.[/color][/color]

This has been suggested before.
[color=blue]
> How about just providing a freeze method on `object` (since everything
> will inherit from object) that can freeze the object?[/color]

Well, the OP suggested this is for 3.0, but it doesn't have to be
unless you use his syntax. But Python generally prefers words to magic
characters, so a "freeze" builtin would be preferable, meaning it
could be done in 2.x.
[color=blue]
> In fact the freeze protocol could provide 2 methods: freeze and
> frozen, the former would freeze the object in place (e.g. freeze the
> object it's applied to) while the later would return a frozen copy of
> the object it's applied to.[/color]

Freezing in place is problematical. For this to work as intended, all
the values in the container have to be frozen as well. All yours and
the OPs examples used immutable values, so this wasn't obvious. But
consider:

d = dict()
l = [d]
l.freeze()

for l to be usable as a dictionary key etc. after the freeze
invocation, d must also be frozen. Doing that in place would be
unfortunate. Creating a frozen copy of d to put in the frozen version
of l might work, but still seems strange.

Furthermore:
[color=blue]
> One could even dream of a melt/molten method pair that'd behave at the
> opposite of the freeze/frozen pair (to have the ability to "unfreeze"
> an object if needed)[/color]

You can't do unmelt in place:

l.freeze()
d.melt()

would leave l not really frozen. You probably want the freeze and melt
to be symmetric, which lets out freezing in place.
[color=blue]
> No new keyword, no new token, no new structure, no new builtin, same
> functionalities .[/color]

Actually, I like the "len" model, which would be a new builtin that
uses the __freeze__ method.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bearophileHUGS@lycos.com]

Re: Freezing

Raymond Hettinger:
[color=blue]
>I'm curious whether you've had an actual use for dictionaries as keys.<[/color]

I've never had this need (probably because it's an unsupported thing to
do too).

[color=blue]
>Likewise, how about frozensets? Have you had occasion to use them as keys? They were created to support sets of sets, yet even that doesn't come-up often.<[/color]

I use sets all the time. And doing a little of mathematics it's rather
common to need subsets too, I have had this "need" 3-4 times. But the
implementation of subsets is "broken" (= no dynamic subsets allowed)
and frozen subsets aren't much useful.

[color=blue]
>So why build a mechanism to automate a process that no one uses?<[/color]

You are right, frozedicts aren't much useful.
Maybe that freezing protocol was useful for user defined objects too.

[color=blue]
>Also note that Guido has said over and over that tuples are NOT frozenlists. Even with a mechanism to freeze lists, tuples won't go away.<[/color]

Lists and fronzensets look like a duplication to me, so the freezing
operation was meant to remove them too.

[color=blue]
>The term "freezing" inaccurately suggests an in-place operation; however, the PythonWay(tm) is to create new objects (i.e. given a mutable set s, the result of frozenset(s) is a new container).<[/color]

It seems sometimes Py doesn't follow its own PythonWay(tm) :-)
But I agree that sometims consistency can be useful.

Thank you for your (good as usual) comments, Raymond.
(Strong rigour is necessary near the last stages, before the actual
implementation of an idea, but in most cases the creation of ideas
works better in a tolerant and more relaxed environment.)

-----------------

Mike Meyer:
[color=blue]
>Freezing in place is problematical. For this to work as intended, all the values in the container have to be frozen as well.<[/color]

Right, I was talking about deep (recursive) freezing in the original
post too.

[color=blue]
>Actually, I like the "len" model, which would be a new builtin that uses the __freeze__ method.<[/color]

Well, I presume this is a matter of personal tastes and consistency
too. This time I appreciate the freeze() too, but probably some people
can think that adding .len, .copy(), .del(), .freeze() methods to most
objects is more regular:

len(l) l.len
copy.copy(l) l.copy()
|l| freeze(l) l.freeze()
del l l.del()

Bye,
bearophile

[James Stroud]

Re: Freezing

bearophileHUGS@ lycos.com wrote:[color=blue]
> Dicts and sets require immutable keys, like tuples or frozensets[/color]

Not really...

def freeze(anobj):
"""returns a new hashable object"""
import copy
try: hash(anobj)
except: pass
else: return copy.deepcopy(a nobj)
class FrozenType(type ):
def __new__(cls, name, bases, dct):
return type.__new__(cl s, name, bases, dct)
def __init__(cls, name, bases, dct):
super(FrozenTyp e, cls).__init__(n ame, bases, dct)
def hashself(self): return hash(repr(self) )
name = 'Frozen_%s' % anobj.__class__ .__name__
bases = (anobj.__class_ _,)
dct = dict(anobj.__cl ass__.__dict__)
dct['__hash__'] = hashself
cls = FrozenType(name , bases, dct)
return cls(anobj)

def test():
class bob:
def doit(self): print 1,2,3,4
# amutable = bob()
# amutable = [1,2,3,4]
amutable = set((1,2,3,4))
# amutable = {1:2, 3:4}
frozen = freeze(amutable )
print frozen
print type(frozen)
adict = {frozen:100}
frozen2 = freeze(amutable )
print adict[frozen2]
print frozen is frozen2
print frozen == frozen2

test()

[Mike Meyer]

Re: Freezing

bearophileHUGS@ lycos.com writes:[color=blue]
> Mike Meyer:[color=green]
>>Actually, I like the "len" model, which would be a new builtin that uses the __freeze__ method.<[/color]
> Well, I presume this is a matter of personal tastes and consistency
> too. This time I appreciate the freeze() too, but probably some people
> can think that adding .len, .copy(), .del(), .freeze() methods to most
> objects is more regular:
>
> len(l) l.len
> copy.copy(l) l.copy()
> |l| freeze(l) l.freeze()
> del l l.del()[/color]

One problem is that it suggests a structure that isn't there. While
other languages will have an abstract "sequence" type that has a len
that, for example, iterates through the elements to count them, Python
doesn't have such a thing. Adding a "len" method would require adding
the method to all the types, even if only to add the default
behavior. A "len" function, on the other hand, can check for __len__,
and implement the default behavior if it doesn't find that (n.b. - I'm
not saying that this is what "len" does; I'm just providing an
example!).

A freeze function could do the same thing: check for __freeze__ and
use that if it exists, otherwise implement a default behavior. In Py3K
you might be able to put the default behavior on object, but only if
everything really inherits from object. I'm not sure the other builtin
types will do that.


<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.