A couple of questions regarding mutabilty:
First, I noticed a comment at the beginning of quadratic_forms/binary_qf.py from Stein: "make immutable". Can anyone (William?) elaborate on what that means? They don't currently (e.g., sage-4.6.1-a3) seem to be very immutable:
sage: q1=BinaryQF((-2,0,1))
sage: q1._a=3
sage: q1
3*x^2 + y^2
Second, on this note, is there anywhere written a discussion of what immutability means in Python? A quick check of the doc (for Python 2.[67]) doesn't seem to lead anywhere. For example, can one declare a "class" immutable and have it stick, or is there extra work involved to ride herd on all "instance variables" that one would want to be unchangeable directly?
Hope that question is clear. Thanks for any comments.
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
--
Democracy is two wolves and a lamb
voting on what to have for lunch.
Liberty is a well-armed lamb contesting
the vote.
sage: q1.discriminant()
8
It's generally unsafe to set underscore attributes directly, as it's
unclear what may be cached or what invariants may need to be
> Second, on this note, is there anywhere written a discussion of what immutability means in Python? A quick check of the doc (for Python 2.[67]) doesn't seem to lead anywhere.
Immutability is just a matter of convention.
> For example, can one declare a "class" immutable and have it stick, or is there extra work involved to ride herd on all "instance variables" that one would want to be unchangeable directly?
As mentioned, one can use __setattr__. It's easy from Cython to make a
class immutable from Python as well.
- Robert
On Dec 26, 2010, at 03:17 , Volker Braun wrote:
> Python has no "const". You can always manually change the innards of your
> class. The set_immutable() is just implemented by hand.
Tuples are "really" immutable, correct? Is this possible because the tuple is an internal data type?
> One could override __setattr__() to catch assignments to existing
> attributes, but I think that is not done anywhere in Sage.
Are 'attributes' the same as (or do they include) instance variables?
Thanks for the clarification.
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
Like the ski resort full of girls hunting for husbands
and husbands hunting for girls, the situation is not
as symmetrical as it might seem.
- Alan MacKay
--
Well, you can change them from Cython :). It's because they're
implemented in C, and (by design) no Python-level "hooks" are created
to mutate them from Python.
>> One could override __setattr__() to catch assignments to existing
>> attributes, but I think that is not done anywhere in Sage.
>
> Are 'attributes' the same as (or do they include) instance variables?
Yes, attributes include variables, methodes, etc. When you do
x.a = var
Then x.__gsetattr(x, a, var)
gets called, which by default just updates the dictionary of attributes of x.
- Robert
> On Sat, Dec 25, 2010 at 5:13 PM, Justin C. Walker <jus...@mac.com> wrote:
>> Hi, all,
>>
>> A couple of questions regarding mutabilty:
>>
>> First, I noticed a comment at the beginning of quadratic_forms/binary_qf.py from Stein: "make immutable". Can anyone (William?) elaborate on what that means? They don't currently (e.g., sage-4.6.1-a3) seem to be very immutable:
>> sage: q1=BinaryQF((-2,0,1))
>> sage: q1._a=3
>> sage: q1
>> 3*x^2 + y^2
>
> sage: q1.discriminant()
> 8
This is "accidental" (because of the @cached_method decoration), right? Anything that refers, uncached, to q._a will pick up the current value of that variable.
Could one remove all mention of _a,_b,_c in the implementation, and keep those values in a tuple? Well, of course, one could. That would make the instance relatively immutable (except for clobbering the whole tuple).
> It's generally unsafe to set underscore attributes directly, as it's
> unclear what may be cached or what invariants may need to be
I understand that aspect of the implementation. I wondered (based on William's comment at the head of the file) whether one really could make the class (or rather, its instances) immutable.
>> Second, on this note, is there anywhere written a discussion of what immutability means in Python? A quick check of the doc (for Python 2.[67]) doesn't seem to lead anywhere.
>
> Immutability is just a matter of convention.
And that means 'no' (except for, say, tuples).
>> For example, can one declare a "class" immutable and have it stick, or is there extra work involved to ride herd on all "instance variables" that one would want to be unchangeable directly?
>
> As mentioned, one can use __setattr__. It's easy from Cython to make a class immutable from Python as well.
This because the implementation is hidden in C, correct? Such a class would not be immune to fiddling from other C code.
Thanks for your comments.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------
> On Mon, Dec 27, 2010 at 11:14 AM, Justin C. Walker <jus...@mac.com> wrote:
>> Thanks for the reply.
>>
>> On Dec 26, 2010, at 03:17 , Volker Braun wrote:
>>
>>> Python has no "const". You can always manually change the innards of your
>>> class. The set_immutable() is just implemented by hand.
>>
>> Tuples are "really" immutable, correct? Is this possible because the tuple is an internal data type?
[snip]
>> Are 'attributes' the same as (or do they include) instance variables?
>
> Yes, attributes include variables, methodes, etc. When you do
>
> x.a = var
>
> Then x.__gsetattr(x, a, var)
>
> gets called, which by default just updates the dictionary of attributes of x.
Ah. That's what I was looking for. I get the picture now. Thanks!
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
Yep.
> Could one remove all mention of _a,_b,_c in the implementation, and keep those values in a tuple? Well, of course, one could. That would make the instance relatively immutable (except for clobbering the whole tuple).
I don't think clobbering the whole tuple would be that much harder,
but it would add an extra level of indirection everywhere.
>> It's generally unsafe to set underscore attributes directly, as it's
>> unclear what may be cached or what invariants may need to be
>
> I understand that aspect of the implementation. I wondered (based on William's comment at the head of the file) whether one really could make the class (or rather, its instances) immutable.
>
>>> Second, on this note, is there anywhere written a discussion of what immutability means in Python? A quick check of the doc (for Python 2.[67]) doesn't seem to lead anywhere.
>>
>> Immutability is just a matter of convention.
>
> And that means 'no' (except for, say, tuples).
>
>>> For example, can one declare a "class" immutable and have it stick, or is there extra work involved to ride herd on all "instance variables" that one would want to be unchangeable directly?
>>
>> As mentioned, one can use __setattr__. It's easy from Cython to make a class immutable from Python as well.
>
> This because the implementation is hidden in C, correct? Such a class would not be immune to fiddling from other C code.
Exactly. The language for the most part doesn't prevent you from
meddling with internals, just in case you need to, but by convention
an underscore is used to denote something internal that you shouldn't
change/call/access unless you really know what you're doing (e.g. as
an implementer of the class itself).
- Robert