Understanding Python from a PHP coder's perspective

Chris Angelico rosuav at gmail.com
Mon Dec 7 22:47:40 EST 2015


On Tue, Dec 8, 2015 at 2:11 PM, Tim Chase <python.list at tim.thechases.com> wrote:
> On 2015-12-08 10:09, Chris Angelico wrote:
>> All three are very different.
>>
>> 1) Process state.
>>
>> You start up a Python program, and it sits there waiting for a
>> request. You give it a request, and get back a response; it goes
>> back to waiting for a request. If you change a global variable, or
>> maintain persistent state, or anything, the next request will 'see'
>> that change. This is completely global.
>
> 1) This is completely global *to the process* (you can have multiple
> Python processes sitting around waiting, taking advantage of multiple
> cores)
>
> 2) This is almost always a bad idea for multiple reasons (it can get
> in the way of scaling, it can produce hard-to-track-down bugs, etc).
> Use a real session store (a database, a key/value store like
> memcached, a NoSQL store like Redis, store session info in cookies,
> etc.) instead.

If your goal is session state, then yes - use something that actually
persists past the process life. But for caches and stuff, where
dropping them has performance implications but nothing else, it makes
good sense to keep them in globals. Particularly if you simply
populate the cache on process load and then never lose it.

ChrisA



More information about the Python-list mailing list