On Sat, 2008-04-05 at 11:31 -0700, mrts wrote:
[...]
> Once Python 2.3/4 support will be dropped, we can start using
> higher-grade hash algorithms from 2.5 hashlib throughout. But
> this is offtopic for current discussion and will not happen in
> the foreseeable future.
It will be a while beyon
Lots of interesting stuff here. Craig has already responded in some
details and I mostly agree with what he's saying. I've addressed a few
more points with specifics to Django's implementation, so there's some
duplicate ground covered, but in a way that is more relevant if you know
the code.
On S
Hey mrts,
On Apr 5, 2:31 pm, mrts <[EMAIL PROTECTED]> wrote:
> The cookies are already signed. Session data +
> settings.SECRET_KEY is md5-digested and tampering raises an
> exception. So in that sense the sessions are already secure.
Sorry, I didn't mean "secure" in the sense that someone can al
As has been said by others, I think this thread is no longer about threads
or even interprocess synchronization. For web apps, the norm is multiple
web servers talking to a single database. This should rule out any form of
synchronization mechanism outside of the database. In fact, the whole po
> Why not write a "secure" session backend? (You would presumably
> also need to require signed cookies for the session.)
The cookies are already signed. Session data +
settings.SECRET_KEY is md5-digested and tampering raises an
exception. So in that sense the sessions are already secure.
Note th
On Apr 4, 11:06 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> (docstrings occupy memory too, so if you're *only* writing for folks
> reading the source, use comments.)
And of course, a production environment can always optimize the doc
strings out.
--~--~-~--~~~---~
On Apr 2, 12:26 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> def get_object_from_cache(self, ...):
> """
> Get an object from the cache and return it.
>
> ...
hmm... the doc string equivalent of the infamous c inanity:
i++ // increment i
I have seen a bit of that in the c
On Mar 26, 5:38 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
wrote:
> * Improving the existing bindings: The existing bindings
> (http://www.pangalactic.org/PyPAM/) are bug-ridden with lot of memory leaks,
> hasn't been tested with python2.5 and don't expose the full C API.
> This part of the projec
This post is *horribly* long. I tried to make it as structured and
accessible as I possibly could. Holding myself back to say the
forbidden words -- a ikiw egap dluow ekam siht erom elbadaer
*chuckle*.
Concurrency at DB level
===
Background
--
The general threading c
Please ask this question on django-users. This group is for
discussions on Django internals only.
[EMAIL PROTECTED] wrote:
> I was thinking of using Lighttp on one of the 760 servers. Is there a "best
> OS" to make setup go smoothly.
>
> Any tips or references are very welcome. I need to develop
I was thinking of using Lighttp on one of the 760 servers. Is there a "best OS"
to make setup go smoothly.
Any tips or references are very welcome. I need to develop then move to
production on same server.
Thanks in advance for any advice.
Keith
--~--~-~--~~~--
Ivan Sagalaev wrote:
> Nobody stops a developer from doing both things in parallel: storing on
> disk and streaming to S3.
> they will gain heavily from not doing writes and
> reads of the whole file on local disk.
Looks like I'm contradicting myself a bit here :-). But it's not the
point act
Malcolm Tredinnick wrote:
> Then those people deserve to be beaten heavily about the head and
> shoulders. S3 is NOT a reliable upload endpoint. They (Amazon) say
> there'll be approximately a 1% failure rate for attempted uploads. As 37
> signals have noted in the past (they use it for their whit
Mike Axiak wrote:
> I didn't want to use the extra setting either, but I finally caved in
> after working with it (and discussing with Ivan). I will certainly
> explore any other possibilities.
My original reason for settings was that a single upload handler can't
possibly know the semantics of
14 matches
Mail list logo
