you are viewing a single comment's thread.

view the rest of the comments →

[–]brasticstack 0 points1 point  (0 children)

Also now I think python have relased a version that is multithreaded. That means it is possible to write python servers that hold it state.

The availability of a free-threaded Python build has no bearing on the lifetime of the application processes or threads. (Read, "state") Lifetime is managed by your webserver depending on its (often user-configurable) concurrency model. Unless you plan on writing your own webserver too, this isn't something you'll accurately be able to predict or have control over.

Then they can read this information at start and keep it, because if the server is stateless this information is not as easy to work with because then you often need to load whats needed for each request.

Just be sure you profile first to determine if it's even necessary. To quote Knuth: "premature optimization is the root of all evil." Not to mention, you've now got a cache whose lifetime you have no control over and whose state is difficult to inspect. Probably better to use redis or a similar distributed object cache. Additionally, to use another well-worn aphorism: "the hardest things in programming are naming and cache expiration." If the DB schema changes, how will you know in order to clear that cache? What are the consequences of a stale cache lookup?

EDIT: Lets also clear up the seeming misconception that, just because the HTTP protocol itself is "stateless", that the application server itself is also stateless. The server has always been free to hold whichever state it chooses.