Just to add to all the ideas, what about using a with statement, eg:

with Immutable():
    # the things Nils wishes were immutable are immutable by default here

On Tue, Aug 10, 2021 at 8:54 PM Nils Bruin <nbr...@sfu.ca> wrote:

> On Tuesday, 10 August 2021 at 18:53:50 UTC-7 Travis Scrimshaw wrote:
>
>> I am -1 on hashability-on-demand for the suggested reason: it could lead
>> to hard-to-track-down bugs in code where we end up calling a hash of
>> something that could be *very* implicit, input to a UniqueRepresentation or
>> a @cached_method/function. As Nils said, the user has no business hashing a
>> mutable object, and we should explicitly tell the user that rather than
>> silently changing it. It violates the principle of least surprise.
>>
>
> At the moment, it's just a conjecture that such scenarios *might* be
> possible. I think we need to see some real-world example where this problem
> arises before we further assess how much we need to mitigate against this.
>
> But that brings us back to the problem that I did not ASK for a mutable
> object! I wanted an immutable one!
>
> V=VectorSpace(GF(2),3)
> v = V.gen(1)
> w = V.gen(2)
> v.set_immutable() #this is annoying, but  OK
> w.set_immutable() #this is again annoying
> D={}
> D[v]=1
> D[w]=2
> D[v+w]=3 #the error here is uncalled for!
>
> If we're going to insist on people expressing intent on whether vectors
> will need to be mutable or immutable, then in parallel with all other
> arithmetic structures, vectors should be by default immutable. If someone
> wants a mutable vector, they should ask for a mutable explicitly. If we'd
> start from scratch I'm pretty sure that's what we would arrive at. So if
> we're going for purity of design, I think we'd need to take the leap and go
> with that.
>
> That's going to
>
>
>> Imagine a bank that gave 50% of all your deposits to charity because it
>> thought that is what you wanted to do because you checked out a charity
>> website, but you only would find out about this when you checked your
>> balance. I would not be happy with this bank.
>>
>
> and I don't see the parallel with the topic here, so let's leave the straw
> men out of it.
>
> --
> 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 sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/9a8aab3c-6b68-4b44-be63-c44bab94e12an%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/9a8aab3c-6b68-4b44-be63-c44bab94e12an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
-- 
-- William Stein

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GDE1F6F0kO0GhrbQVMJGThiLbZJwsgAJK00ZvyrGsafeA%40mail.gmail.com.

Reply via email to