Freezing

Discussion in 'Python' started by bearophileHUGS@lycos.com, Jan 12, 2006.

  1. Guest

    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, 2006
    #1
    1. Advertising

  2. Guest

    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, 2006
    #2
    1. Advertising

  3. Xavier Morel Guest

    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.
    Xavier Morel, Jan 12, 2006
    #3
  4. 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
    Raymond Hettinger, Jan 12, 2006
    #4
  5. Mike Meyer Guest

    Xavier Morel <> writes:
    > 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.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
    Mike Meyer, Jan 12, 2006
    #5
  6. Guest

    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, 2006
    #6
  7. James Stroud Guest

    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()
    James Stroud, Jan 14, 2006
    #7
  8. Mike Meyer Guest

    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.


    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
    Mike Meyer, Jan 14, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Kievlan

    ASP.NET freezing

    John Kievlan, Aug 7, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    1,522
    John Kievlan
    Aug 7, 2003
  2. =?Utf-8?B?U3RldmVuIEs=?=

    IIS / ASP.NET freezing computer

    =?Utf-8?B?U3RldmVuIEs=?=, Mar 13, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    494
    Alvin Bruney [ASP.NET MVP]
    Mar 22, 2005
  3. =?Utf-8?B?Sm9obiBXYWxrZXI=?=

    Freezing Datagrid Column Headers

    =?Utf-8?B?Sm9obiBXYWxrZXI=?=, Jan 18, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    2,956
    =?Utf-8?B?Sm9obiBXYWxrZXI=?=
    Jan 18, 2006
  4. =?Utf-8?B?RGFu?=
    Replies:
    7
    Views:
    1,012
  5. Mitch
    Replies:
    2
    Views:
    553
    Mitch
    Mar 13, 2006
Loading...

Share This Page