428,705 Members | 1,301 Online
Need help? Post your question and get tips & solutions from a community of 428,705 IT Pros & Developers. It's quick & easy.

# Freezing

 P: n/a 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 Jan 12 '06 #1
7 Replies

 P: n/a 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 Jan 12 '06 #2

 P: n/a be************@lycos.com wrote: 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 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: l = [0, 1, 2, 3] l.append(5) l [0, 1, 2, 3, 5] l.frozen() [0, 1, 2, 3, 5] fl = l.frozen() l.append(7) l [0, 1, 2, 3, 5, 7] fl.append(7) Traceback (most recent call last): .... WhateverError: frozen 'list' object cannot modified fl [0, 1, 2, 3, 5] l.freeze() l [0, 1, 2, 3, 5, 7] l.append(9) 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. Jan 12 '06 #3

 P: n/a be************@lycos.com wrote: add a freeze operation, to freeze lists, sets and dicts (etc), so they can be used as keys. 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(mydict.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 Jan 12 '06 #4

 P: n/a Xavier Morel writes:be************@lycos.com wrote: 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. This has been suggested before. How about just providing a freeze method on `object` (since everything will inherit from object) that can freeze the object? 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. 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. 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: 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) 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. No new keyword, no new token, no new structure, no new builtin, same functionalities. Actually, I like the "len" model, which would be a new builtin that uses the __freeze__ method. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. Jan 13 '06 #5

 P: n/a Raymond Hettinger: I'm curious whether you've had an actual use for dictionaries as keys.< I've never had this need (probably because it's an unsupported thing to do too). 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.< 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. So why build a mechanism to automate a process that no one uses?< You are right, frozedicts aren't much useful. Maybe that freezing protocol was useful for user defined objects too. 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.< Lists and fronzensets look like a duplication to me, so the freezing operation was meant to remove them too. 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).< 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: Freezing in place is problematical. For this to work as intended, all the values in the container have to be frozen as well.< Right, I was talking about deep (recursive) freezing in the original post too. Actually, I like the "len" model, which would be a new builtin that uses the __freeze__ method.< 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 Jan 13 '06 #6

 P: n/a be************@lycos.com wrote: Dicts and sets require immutable keys, like tuples or frozensets Not really... def freeze(anobj): """returns a new hashable object""" import copy try: hash(anobj) except: pass else: return copy.deepcopy(anobj) class FrozenType(type): def __new__(cls, name, bases, dct): return type.__new__(cls, name, bases, dct) def __init__(cls, name, bases, dct): super(FrozenType, cls).__init__(name, bases, dct) def hashself(self): return hash(repr(self)) name = 'Frozen_%s' % anobj.__class__.__name__ bases = (anobj.__class__,) dct = dict(anobj.__class__.__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() Jan 14 '06 #7

 P: n/a be************@lycos.com writes: Mike Meyer:Actually, I like the "len" model, which would be a new builtin that uses the __freeze__ method.< 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() 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. Jan 14 '06 #8

### This discussion thread is closed

Replies have been disabled for this discussion.