On Tuesday, August 10, 2021 at 11:27:35 PM UTC-7 vdelecroix wrote:
>
> It could even be refined to
>
> with Immutable(V):
> # elements of V are now immutable by default
>
> But even then, some code elsewhere in sage might use the very same
> parent (eg ZZ^2 is unique). This parent might want
Le 11/08/2021 à 08:09, Nils Bruin a écrit :
On Tuesday, 10 August 2021 at 21:10:43 UTC-7 wst...@gmail.com wrote:
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
That would
On Tuesday, 10 August 2021 at 21:10:43 UTC-7 wst...@gmail.com wrote:
> 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
>
That would basically move the "unless otherwise
On Tuesday, 10 August 2021 at 20:54:02 UTC-7 Nils Bruin wrote:
>
> 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!
>
> It's actually
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 wrote:
> On Tuesday, 10 August 2021 at 18:53:50 UTC-7 Travis Scrimshaw wrote:
>
>> I am -1
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
>
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
On Wednesday, August 11, 2021 at 7:39:14 AM UTC+9 Nils Bruin wrote:
> The semantics are actually quite straightforward: it's
> hashability-on-demand.
>
The demand is implicit and not explicitly demanded, like set_immutable(),
by the user. We may imagine a situation that this causes a
On Tuesday, August 10, 2021 at 3:39:14 PM UTC-7 Nils Bruin wrote:
> On Tuesday, 10 August 2021 at 09:46:44 UTC-7 Matthias Koeppe wrote:
>
>> On Monday, August 9, 2021 at 7:43:29 PM UTC-7 Lorenz Panny wrote:
>>
>>> Have we considered the idea to simply call self.set_immutable() whenever
>>>
On Tuesday, 10 August 2021 at 09:46:44 UTC-7 Matthias Koeppe wrote:
> On Monday, August 9, 2021 at 7:43:29 PM UTC-7 Lorenz Panny wrote:
>
>> Have we considered the idea to simply call self.set_immutable() whenever
>> __hash__ is invoked?
>>
>
> -1 on this; too complicated semantics
>
The
On Monday, August 9, 2021 at 7:43:29 PM UTC-7 Lorenz Panny wrote:
> Have we considered the idea to simply call self.set_immutable() whenever
> __hash__ is invoked?
>
-1 on this; too complicated semantics
--
You received this message because you are subscribed to the Google Groups
I actually like this idea a lot. My main concern is that it may not be
immediately clear where a hash is being called for a user (for example,
using it as an argument to a @cached_method will call __hash__). So when
they try to mutate the vector/matrix and it fails, it may be difficult for
them
On Monday, 9 August 2021 at 19:43:29 UTC-7 Lorenz Panny wrote:
> Have we considered the idea to simply call self.set_immutable() whenever
> __hash__ is invoked? I think that would solve Nils' original problem
It would solve my problem and it would avoid a whole bunch of problems we'd
have with
Have we considered the idea to simply call self.set_immutable() whenever
__hash__ is invoked? I think that would solve Nils' original problem and
it would mean things run smoothly for users who don't know about mutable
and immutable objects. In that case, the exception for trying to modify
Hi all,
I am fully aware of why vectors *can* be mutable and that having them start
out life mutable makes sense (since you cannot really change an immutable
vector back to mutable), but there is a scenario where it's super annoying.
I ran into this recently in an actual practical piece of
15 matches
Mail list logo
