I'm new to WebDev, explain to me why or why it wouldn't be OK for all users to access a global Lark() parser object?

By lark parser generator pyhon lib I mean:


I’m just thinking if everyone tries to use the same parser object something inside of it might cause an error. OTOH, I don’t know how web servers work exactly…


There are no such things as “global objects” within a production-quality Django deployment. It doesn’t even make sense to suggest this.

In a typical environment, you’re going to have multiple instances of the Python interpreter running, each with their own set of loaded modules. They’re all independent of each other.
And those processes can, when necessary or appropriate, be restarted. So anything set up specifically within an instance would need to be reloaded.

(Yes, there are exceptions to the above, but you would know if you were dealing with one of them.)

1 Like

@KenWhitesell I’m not sure what you’re suggesting though. Are you suggesting that I just stick the parser in a regular global and each user actually will have their own instance? Or are you suggesting that for each user I put the parser object in their Django session?


No, NO globals.

The way Django works is that when a request comes in, Django (the framework) calls a “view”. This view is responsible for creating all objects needed by that invocation of that view. When the view has finished, those objects are disposed of.

Data that needs to be persisted between requests need to be stored externally to the Django process. (Database, memcache, redis, etc)

It may help if you provided more specifics about what it is you’re actually trying to accomplish here.

1 Like

Ken, hope I’m not too late here, but let’s say you have an object with a reference to a subprocess that you would like a persistent reference to. In this case you can’t pickle the object to cache it. How would you handle this situation with Django?

I’m not sure I understand the specific use-case here. The way you’ve worded your question makes me think this is an XY Problem type of situation.

I’ve written multiple answers here explaining why I think that any attempt to manage a sub-process from within a Django application is a wrong approach to a solution for a problem. I’ve also detailed in a couple of cases how I’ve resolved that generic type of issue in different ways.

The selection of an appropriate solution is highly dependent upon the context of the requirements being addressed, and so I don’t believe that there is one generic answer that fits the “one-size, fits-all” approach.

@KenWhitesell Can you provide a link(s) to your answers on managing sub-processes from Django? My searches on “manage a sub-process” and “sub-process” did not yield anything. I’ll write a more detailed question. Thanks!

Agreed - generally speaking you’d need to be searching for Celery, cron, or management commands to find these. Those are the common mechanisms for managing processes external to Django.

Posting these in no particular order, as I find them:

Using redis as a communication channel between Django and an external process:

One specific comment regarding external processes:

Managing external processes (see the entire thread):

Single comments I’ll highlight: