Simplejson has been getting some version increments lately and Django
hasn't been including them (there are tickets), which is - in my
opinion - okay. Constantly upgrading the included simplejson library
is an never ending rabbit chase where required effort doesn't motivate
possible benefits (read
On Nov 28, 2008, at 10:56, Johan Bergström wrote:
> I still wonder if there's a better solution for somehow allowing users
> to drop in their own simplejson without resorting to edit
> django.utils.simplejson or overriding sys.modules. This would reduce
> the need for upgrading the bundled package
I currently use my own versions of `send_mail` and `mail_*`, which
hijack the recipients if DEBUG is True. The idea being that I don't
want to send real emails to real recipients while developing,
debugging and testing.
In this case I get real emails delivered to everyone listed in
`settings.ADMI
It seems like cache keys need to be created using various
cross-cutting bits of data. As an example, maybe I have localized
data, and any caching should include the requestor's locale, but also
the content type / object ID, and maybe some other consumer
differentiation.
This sort of key generat
So, I've had a good look over the (constantly-growing!) code here, and
I'm really beginning to like the decorator approach, especially the nice
way you combine dependencies with the dependency classes, which makes my
solution to old/new FK values look terrible.
I still have two issues, although I
I'd be -1, that would mean storing some sort of global(thread local
probably) instance of the request, plus any other object that you'd
want to cache on. And that just seems like a bad idea. There's no
reason a developer can't create a simple function that takes a few
objects(maybe the obj/query
On Fri, Nov 28, 2008 at 7:15 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> I'd be -1, that would mean storing some sort of global(thread local
> probably) instance of the request, plus any other object that you'd
> want to cache on. And that just seems like a bad idea. There's no
> reason
On Fri, 2008-11-28 at 01:56 -0800, Johan Bergström wrote:
> Simplejson has been getting some version increments lately and Django
> hasn't been including them (there are tickets), which is - in my
> opinion - okay. Constantly upgrading the included simplejson library
> is an never ending rabbit c
On Fri, 2008-11-28 at 08:18 -0600, Jeremy Dunck wrote:
> It seems like cache keys need to be created using various
> cross-cutting bits of data. As an example, maybe I have localized
> data, and any caching should include the requestor's locale, but also
> the content type / object ID, and mayb
I think there's actually a big win in favoring a system-installed
simplejson over Django's included version. The system-installed
package is actually orders of magnitude faster than Django's included
version. That's reason enough to do some small code changes. In my
opinion, this could all be s
On Fri, 2008-11-28 at 19:05 -0800, [EMAIL PROTECTED] wrote:
> I think there's actually a big win in favoring a system-installed
> simplejson over Django's included version. The system-installed
> package is actually orders of magnitude faster than Django's included
> version.
That's a bit of
On Nov 28, 7:31 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> That's a bit of a universal claim and not really supportable. You don't
> know what version the "system installed" one is for every system out
> there. In some cases, the installed version will be slower.
Very good point. Thanks
12 matches
Mail list logo
