> What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend,

I have worked on a lot of projects that involve science related stuff and Django.

Directly in the web app backend was relevant mostly for GIS apps that could take large raster data, process it based on the user's wishes, apply the right projections, apply a colormap and return an image to be shown on a map. Python has great tools for that sort of thing and it doesn't have to take much longer than rendering a HTML template does.

Other than that, the CPU intensive science-related stuff usually ran in background tasks, with Celery or otherwise. But those would still need access to the database, so why not use the same Django models for the web backend and the background tasks.

I find that once Django is part of your Python code it tends to find its way to all parts of it, through the ORM, settings files, handy admin interfaces, management commands as scripts, and so on.

Of course anything long running is going to be run as a service via something like Celery. That being said, there are actually a lot of things you can do with SciPy for which the turnaround time isn't sufficient to justify dispatching multiple messages.

Come one, even scientific work will require a front end at some point. Not everything will be CPU intensive. And even if it is it may need some user interaction to get the task started - even if it is just uploading data to be processed offline.

But you don't need the scientific code inside your Django app—it should live in a separate process. What I'm saying is there is no need to have the scientific code directly inside the Django app.

There are plenty of web based scientific apps. Genome browsers for example. Why would you have those in a separate process, when its essentially a crud app?