I have now seen this happen with other data that has expired in the
session. What I am seeing is that any key:value pair that times out
when stored in the request.session is replaced by key:True
Is this expected behaviour?
-Daniel
--
You received this message because you are subscribed to the
> This sounds suspicious to me. There is actually no "installation"
> procedure for Python stuff. It's all about priority in the sys.path, or
> PYTHON_PATH, environment variable. So you might experience glitches because
> some bits of 1.2 are used together with some other bits of 1.0.
>
> C
On 03/set/2010, at 17:42, "daniel.osterme...@gmail.com"
wrote:
> There was another issue raised that sounded a little similar, where
> the problem was the that django 1.2 was installed over the top of
> 1.0. I've installed it as documented, but I do have both 1.0 and 1.2
> installed, so maybe s
> do you run into the same problem if you remove that 'optiver' stuff?
I can not say that I have tried. That is the application that I am
developing. The only point of interest in it would be that non of the
views require a login, and whilst I make use of the request.session,
I've checked and
Hi,
On Sep 3, 2010, at 7:42 AM, daniel.osterme...@gmail.com wrote:
> Any help would be appreciated.
do you run into the same problem if you remove that 'optiver' stuff?
-- Fede
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post
Hi,
Ive been running into a problem lately (not sure when it started)
where I receive an AttributeError when logging into the admin site.
The circumstances seem to be that I start the application, go to the
admin site (and log in successfully), navigate around the rest of the
application (which doe
6 matches
Mail list logo
