That's exactly what I'm thinking about. Unfortunately, it's not brought to
the attention among Django developers so far.
On Tuesday, 20 May 2014 02:01:55 UTC-6, Tai Lee wrote:
>
> Right now it seems that for a generic app to support the possibility of
> being installed in a URLconf with a namesp
+1
> On Oct 25, 2015, at 23:09, charettes wrote:
>
> Now that Curtis did all the investigation work I think it wouldn't hurt being
> consistent here.
>
> __get__(self, instance, cls=None) and __set__(self, instance, value) look
> like sane defaults to me.
>
> Le samedi 24 octobre 2015 18:36:
Thanks for explaining! :)
That makes perfect sense. I didn’t think about mutable objects, sorry!
Bertrand
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving e
Hi Bertrand,
One reason I see for the locmem cache to pickles the data is stores would
be to prevent mutable objects from being shared between threads.
e.g.
Thread one stores [1,2,3] as 'foo', keeps a reference to it to alter it.
Thread two gets 'foo' and alters it.
And to prevent memory leaks
Now that Curtis did all the investigation work I think it wouldn't hurt
being consistent here.
__get__(self, instance, cls=None) and __set__(self, instance, value) look
like sane defaults to me.
Le samedi 24 octobre 2015 18:36:32 UTC-4, Tim Graham a écrit :
>
> Curtis, or should I say FunkyBob,
Hi everyone,
Is there a valid reason why locmem is pickling data?
>From what I understand, locmem is doing that just because its behaviour was
copied from other caches.
But since locmem is basically just a dictionary stored in the current
Python process without persistence, there is no need to s
