#14535: Mutability of Graphs
------------------------------------+---------------------------------------
       Reporter:  SimonKing         |         Owner:  jason, ncohen, rlm
           Type:  enhancement       |        Status:  needs_review      
       Priority:  major             |     Milestone:  sage-5.10         
      Component:  graph theory      |    Resolution:                    
       Keywords:  mutability graph  |   Work issues:                    
Report Upstream:  N/A               |     Reviewers:                    
        Authors:  Simon King        |     Merged in:                    
   Dependencies:  #14524            |      Stopgaps:                    
------------------------------------+---------------------------------------

Comment (by SimonKing):

 Replying to [comment:16 nbruin]:
 > I hope that last line remains fantasy: Changing the mutability of an
 object is a mutation, so should be forbidden on an immutable object (the
 only case where `g.mutable(True)` should succeed is when `g` is already
 mutable).

 Sure it is a mutation. However, I was told a couple of times that the
 "pythonic way" is to pretend that programmers are adult people who know
 what they do and who are prepared to take responsibility for their
 actions. Hence, while there should be some protection against accidental
 changes to an immutable object, it should still be possible to work around
 the protection.

 I conclude that it would be the anti-pythonic way to
 - allow to make a mutable object immutable, but not the other way (this is
 by making `_is_immutable` a cdef attribute, and restrict the interface to
 three methods `is_immutable`, `is_mutable` and `set_immutable`)
 - make it virtually impossible that a sub-class overrides a mutation-
 protected method by a method that does not check for mutation (this is
 possible with metaclasses)
 - turn an object into an immutable object as soon as its hash is computed,
 so that its hash bucket will henceforth never change.

 We need to find a reasonable middle way between the overly permissive
 approach ("all graphs are mutable ''and'' hashable, the programmer really
 has to be careful") and the overly protective approach (as described in
 the bulleted list).

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14535#comment:17>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to