On Thu, Oct 6, 2011 at 9:28 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:

As I was working on some code today, I found myself in a situation where I wanted to "freeze" an object.  This topic has come up a few times since I've been following these lists, so I figured it wasn't too crazy an idea.

Really quickly I hacked out a simple bit of code that I am using for what I needed, and later I posted it as a recipe on the ActiveState cookbook[1].  The gist of it is a __freeze__/__unfreeze__ protocol, supported respectively by two ABCs and two functions (freeze and unfreeze).

I've come to learn that it's a good idea to do some digging in the list archives before posting an idea, and I'm glad I did.  Apparently there is a nearly identical PEP (351) to what I was thinking of [2]. And just my luck, it was shot down pretty hard.

So I have a couple questions.  First, from what I've read so far, the idea of frozen/immutable seems to be tied pretty closely to being hashable.  However, this wasn't applicable to the use case that I had.  Instead, I just wanted to make sure certain attributes of a class of mine were effectively read-only.  So, is being hashable necessarily tied to being immutable?

Second, I realize that PEP 351 failed to pass muster, so I'm not holding my breath here.  Shoot, I'm not even really proposing we add this protocol.  Mostly, I found a simple model that worked for me and seemed more broadly applicable; and I wanted to see if it would be suitable for further research.  Now, in light of PEP 351, I'm less convinced that it's so simple.  Still, I've seen some ideas come back from the proverbial grave and wanted to see if this one is not quite dead, sir (or if I should avenge it <wink>).

-eric

[1] http://code.activestate.com/recipes/577895/ [2] http://www.python.org/dev/peps/pep-0351/

Okay, it's like Raymond was reading my mind in some of what he says here: http://mail.python.org/pipermail/python-dev/2006-February/060802.html Now I'm gonna have to go back consider if there is a better way to do the read-only bit I mentioned earlier (which motivated this post). My only hope is that he is talking about something else. :) Regardless, I suppose the recipe will stand or fall on its own anyway. -eric p.s. Greg Ewing also makes a pretty good point: http://mail.python.org/pipermail/python-dev/2006-February/060822.html

Eric Snow wrote:

So, is being hashable necessarily tied to being immutable?

It's tied to immutability of those aspects involved in equality comparison. If a type is to behave predictably when used as a dict key, then two instances that compare equal must always compare equal, and the converse. Attributes that don't affect equality comparison are free to change, however. -- Greg

On Thu, Oct 6, 2011 at 9:28 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:

As I was working on some code today, I found myself in a situation where I wanted to "freeze" an object.  This topic has come up a few times since I've been following these lists, so I figured it wasn't too crazy an idea.

Really quickly I hacked out a simple bit of code that I am using for what I needed, and later I posted it as a recipe on the ActiveState cookbook[1].  The gist of it is a __freeze__/__unfreeze__ protocol, supported respectively by two ABCs and two functions (freeze and unfreeze).

I've come to learn that it's a good idea to do some digging in the list archives before posting an idea, and I'm glad I did.  Apparently there is a nearly identical PEP (351) to what I was thinking of [2]. And just my luck, it was shot down pretty hard.

So I have a couple questions.  First, from what I've read so far, the idea of frozen/immutable seems to be tied pretty closely to being hashable.  However, this wasn't applicable to the use case that I had.  Instead, I just wanted to make sure certain attributes of a class of mine were effectively read-only.  So, is being hashable necessarily tied to being immutable?

Second, I realize that PEP 351 failed to pass muster, so I'm not holding my breath here.  Shoot, I'm not even really proposing we add this protocol.  Mostly, I found a simple model that worked for me and seemed more broadly applicable; and I wanted to see if it would be suitable for further research.  Now, in light of PEP 351, I'm less convinced that it's so simple.  Still, I've seen some ideas come back from the proverbial grave and wanted to see if this one is not quite dead, sir (or if I should avenge it <wink>).

-eric

[1] http://code.activestate.com/recipes/577895/ [2] http://www.python.org/dev/peps/pep-0351/

Okay, it's like Raymond was reading my mind in some of what he says here: http://mail.python.org/pipermail/python-dev/2006-February/060802.html Now I'm gonna have to go back consider if there is a better way to do the read-only bit I mentioned earlier (which motivated this post). My only hope is that he is talking about something else. :) Regardless, I suppose the recipe will stand or fall on its own anyway. -eric p.s. Greg Ewing also makes a pretty good point: http://mail.python.org/pipermail/python-dev/2006-February/060822.html

Eric Snow wrote:

So, is being hashable necessarily tied to being immutable?

It's tied to immutability of those aspects involved in equality comparison. If a type is to behave predictably when used as a dict key, then two instances that compare equal must always compare equal, and the converse. Attributes that don't affect equality comparison are free to change, however. -- Greg