Revision history [back]

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..

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..

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.