On Saturday, November 19, 2011, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Thanks for the reply Russ.
> I think ultimately it comes down to the fact that it was difficult to
figure out what was happening, where as the actual fix itself (as you
mentioned belo
Thanks for the reply Russ.
I think ultimately it comes down to the fact that it was difficult to
figure out what was happening, where as the actual fix itself (as you
mentioned below) is a simple 2 or 3 line code change.
Now that I've thought about it more, I totally agree that my original
sugges
On 18 November 2011 16:57, Anssi Kääriäinen wrote:
> My point is that it would be very useful to know you are actually
> using aware datetimes internally. Especially when migrating an old
> project to use this feature, it is easy to miss some places that do
> not use aware datetimes. And you might
On Sat, Nov 19, 2011 at 4:08 PM, Cal Leeming [Simplicity Media Ltd]
wrote:
> Hi,
> Since the release of 1.3, Django has changed the way it generates the
> memcache key name.
> If I was to do:
> cache.set('hello', 'world', 300)
> It would actually store the result as ":1:hello". Obviously, this is
Hi Dennis,
I would hazard to say that ExceptionReporter/get_traceback_html() is not
public API (it's not listed anywhere in documentation) - and as such it
would be the user implementation of this which is the bug, not
the get_traceback_html method itself (i.e. you'd need to prevent this
condition
Hi,
Since the release of 1.3, Django has changed the way it generates the
memcache key name.
If I was to do:
cache.set('hello', 'world', 300)
It would actually store the result as ":1:hello". Obviously, this is
because the version number is stored, along with the key prefix.
But, this inherentl
