1 | initial version |

Too long for a comment. Playing games with the mutability isn't a solution, it's a problem waiting to happen!

Tik, if you're going to do this, it would be "v._is_immutable = False", with "is" instead of "set", two ms, and different capitalization on False: remember that Python is case-sensitive. (Think "impossible" to get the spelling right, and don't blame me for the inconsistency. :^) I'd also be quite surprised if this were documented: single-underscore variables are usually considered private, and you often don't even document changes in them beween versions.

But bypassing the interface and changing the internal state directly is a bad idea -- if someone provides a setter they probably did it for a reason -- and a way to cause hard-to-detect bugs, because then you can make all sorts of mistakes that the immutability was trying to prevent you from making.

```
sage: u = Sequence([0,1,2,3,5])
sage: v = Sequence([0,1,2,3,4])
sage: hash(u)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: immutable sequences are unhashable
sage: # [Hey, there's a typo: this should be "
```*mutable* sequences are unhashable". Anyone with commit privs, please fix.]
sage: u.set_immutable()
sage: v.set_immutable()
sage: hash(u)
-3958796579501393844
sage:
sage: d = {u: 3, v: 4} # since they're immutable we can hash them, and use them as dictionary keys
sage: d
{[0, 1, 2, 3, 5]: 3, [0, 1, 2, 3, 4]: 4}
sage:
sage: u[4] = 4
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: object is immutable; please change a copy instead.
sage: u._is_immutable = False # don't do this!
sage: u[4] = 4
sage: d
{[0, 1, 2, 3, 4]: 3, [0, 1, 2, 3, 4]: 4}
sage: # what?!

With Python people usually don't go out of their way to prevent you from making mistakes the way they do in (e.g.) C++, and so all sorts of things are possible. But with this power comes responsibility, namely the responsibility not to shoot yourself in the foot when there's no need to..

2 | No.2 Revision |

Too long for a comment. Playing games with the mutability isn't a solution, it's a problem waiting to happen!

Tik, if you're going to do this, it would be "v._is_immutable = False", with "is" instead of "set", two ms, and different capitalization on False: remember that Python is case-sensitive. (Think "impossible" to get the spelling right, and don't blame me for the inconsistency. :^) I'd also be quite surprised if this were documented: single-underscore variables are usually considered private, and you often don't even document changes in them beween versions.

But bypassing the interface and changing the internal state directly is a bad idea -- if someone provides a setter they probably did it for a reason -- and a way to cause hard-to-detect bugs, because then you can make all sorts of mistakes that the immutability was trying to prevent you from making.

```
sage: u = Sequence([0,1,2,3,5])
sage: v = Sequence([0,1,2,3,4])
sage: hash(u)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: immutable sequences are unhashable
sage: # [Hey, there's a typo: this should be "
```*mutable* sequences are ~~unhashable". ~~unhashable".
sage: # Anyone with commit privs, please fix.]
sage: u.set_immutable()
sage: v.set_immutable()
sage: hash(u)
-3958796579501393844
sage:
sage: d = {u: 3, v: 4} # since they're immutable we can hash them, and use them as dictionary keys
sage: d
{[0, 1, 2, 3, 5]: 3, [0, 1, 2, 3, 4]: 4}
sage:
sage: u[4] = 4
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: object is immutable; please change a copy instead.
sage: u._is_immutable = False # don't do this!
sage: u[4] = 4
sage: d
{[0, 1, 2, 3, 4]: 3, [0, 1, 2, 3, 4]: 4}
sage: # what?!

With Python people usually don't go out of their way to prevent you from making mistakes the way they do in (e.g.) C++, and so all sorts of things are possible. But with this power comes responsibility, namely the responsibility not to shoot yourself in the foot when there's no need to..

3 | No.3 Revision |

Too long for a comment. Playing games with the mutability isn't a solution, it's a problem waiting to happen!

Tik, if you're going to do this, it would be "v._is_immutable = False", with "is" instead of "set", two ms, and different capitalization on False: remember that Python is case-sensitive. (Think "impossible" to get the spelling right, and don't blame me for the inconsistency. :^) I'd also be quite surprised if this were documented: single-underscore variables are usually considered private, and you often don't even document changes in them beween versions.

But bypassing the interface and changing the internal state directly is a bad idea -- if someone provides a setter they probably did it for a reason -- and a way to cause hard-to-detect bugs, because then you can make all sorts of mistakes that the immutability was trying to prevent you from making.

```
sage: u = Sequence([0,1,2,3,5])
sage: v = Sequence([0,1,2,3,4])
sage: hash(u)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: immutable sequences are unhashable
sage: # [Hey, there's a typo: this should be "
```*mutable* sequences are unhashable".
sage: # Anyone with commit privs, please fix.]
sage: u.set_immutable()
sage: v.set_immutable()
sage: hash(u)
-3958796579501393844
sage:
sage: d = {u: 3, v: 4} # since they're immutable we can hash them, and use them as dictionary keys
sage: d
{[0, 1, 2, 3, 5]: 3, [0, 1, 2, 3, 4]: 4}
sage:
sage: u[4] = 4
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
[...]
ValueError: object is immutable; please change a copy instead.
sage: u._is_immutable = False # don't do this!
sage: u[4] = 4
sage: d
{[0, 1, 2, 3, 4]: 3, [0, 1, 2, 3, 4]: 4}
sage: # what?!

With Python people usually don't go out of their way to prevent you from making mistakes the way they do in (e.g.) C++, and so all sorts of things are possible. But with this power comes responsibility, namely the responsibility not to shoot yourself in the foot when there's no need ~~to..~~to.

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.