On Mon, May 28, 2018 at 6:11 PM, Nils Bruin <[email protected]> wrote: > On Monday, May 28, 2018 at 7:24:31 AM UTC-7, Simon King wrote: >> >> However, I find your notion of immutability ("do not allow assigning >> attributes and make all existing attributes immutable") far too narrow. >> IIRC, immutable means that once the object is created, its equivalence >> class with respect to the "==" operator will be preserved no matter what >> of its (no-underscore?) methods are called. >> >> Thus, I believe it must be allowed to assign to an attribute of object X, >> as long as the behaviour of X==Y remains unchanged for all objects Y >> (and of course hash(X) doesn't change either). > > > That's a definition of "immutable" that suffices for using things as keys in > dictionaries. However, if the object you created might be referenced > elsewhere, in totally unrelated code (because that code happens to have > called PolynomialRing(Rationals(),names=['x','y']) as well) then you need to > be a *lot* more careful. I'm not sure that locking some objects completely > from mutation would be a feasible solution (it will be nearly impossible to > enforce in python, and we might not be able to get proper performance with > it), but if programmers don't take this very seriously we'll end up with a > code base that is very difficult to reason about. > > The conflation of the two notions of immutability, and the different levels > of enforcement required for them, is what worries me about > UniqueRepresentation. Originally, the use of UniqueRepresentation was > required to ensure the system could *repeatedly* produce identical objects > automatically, based on input parameters, see > https://trac.sagemath.org/ticket/25388#comment:10 . It has the side-effect > of allowing quick equality-by-identity checking. So it may *look* like > UniqueRepresentation is a great way of speeding up "==" and "hash" for > things that are immutable, but it requires a much higher level of > immutability than required for hash. > > (and in practice, the memory leaks caused by UniqueRepresentation bite us > with clockwork regularity)
Could you actually point me to one of those memory leaks? I'm sure they exist but I'm still not clear on how this happens. I suspect it could be improved, and I would like to look into how... -- You received this message because you are subscribed to the Google Groups "sage-devel" 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
