Mod_python development resumes after a 5 year pause | Hacker News Reader

Mod_python development resumes after a 5 year pause

grisha.org

47 pointsgtrubetskoy15 comments

This seems ill advised. He should really justify why he is doing this, and why, in particular, it makes sense for mod_python to gain python3 support.

I don't know of any currently-developed framework that hasn't deprecated mod_python, and for good reason. wsgi and uwsgi are superior solutions in every way. I don't want my python code running within the Apache process.

I am in the process of migrating all of my development to uWSGI. This also has the advantage of entirely de-coupling from Apache, so that I may move a given app to nginx at will.

> He should really justify why he is doing this..

Why?

If he wants to work on mod_python and make it support python3 why shouldn't he?

> I don't want my python code running within the Apache process.

Good for you but no ones forcing you to use it for your code, so you do your thing and if hacking on mod_python makes him happy why shouldn't he?

Now if he was working on mod_cobol you'd have a point... :)

"At #python.web we warn against using mod_python."

Some pretty good reasons are listed at: http://wiki.python.org/moin/PoundPythonWeb/mod_python

Django also is hoping to deprecate mod_python in the future: https://docs.djangoproject.com/en/1.2/howto/deployment/modpy...

Correction: Django isn't "hoping" to deprecate mod_python in the future, we already did it.

You linked to documentation for Django 1.2; the current release, 1.5, does not include mod_python support in the framework. WSGI is now the only deployment option supported in Django itself.

Well, awk. That's what happened when I searched for "mod_python" and "django"; I guess I know why it didn't show up in the later versions.

Ive been using mod_wsgi for some time, and it has worked great, and I had kind of assumed it had superseded mod_python. Wonder what the benefit of bringing it back to life is.

mod_python was already considered borderline-obsolete by the time I started seriously working with Python, so I never did much with it and can't speak authoritatively to its particular capabilities, but one advantage some of the "mod_[language]"s had was being able to integrate closely with Apache in ways that otherwise required writing a C module. As I recall from an earlier life, mod_perl was especially powerful in this regard.

That said, I don't think I'd use any such server-specific modules today. I'm very fond of the model of something like Apache or nginx as a proxy in front of things like gunicorn or Go's net/http library.

I was wondering that, too. Seems like he'd be better served contributing to mod_wsgi if he's got the itch to play again. It's going to be a whole lot of work to catch up again.

I use mod_python, and the only reason I see to switch to mod_wsgi is "mod_wsgi is maintained": it has nowhere near the functionality that mod_python did, and as far as I can tell runs the Python code in separate processes (which will result in even more context switches and data marshaling). I currently am using Apache with mpm_event and mod_python using Apache's SSI to do sub-request compositing between different systems all within the same embedded Python VMs.

Honestly, I've always been under the impression that mod_wagi is the project that needed to catch up... WSGI as an API mostly seems to be about attempting to rebuild some of the stuff Apache has had in place, in an implementation-agnostic fashion, for well over a decade (like the middleware stuff, which they are still having troubles integrating with "write callables", something that seems to be a non-issue with Apache filters).

We're not talking fire-and-forget software here so that's a very long delay to catch up to.

On one hand, I'm glad this isn't going into obscurity (hopefully). I don't like to see projects fade and die out completely simply due to neglect. On the other, I can't see how this will become relevant anytime soon for any new project or even existing one. For that matter, I'm seeing fewer instances where Apache itself is still relevant in new projects these days.

From simple file serving to complex web apps, Nginx has pretty much taken over by and large, so unless Apache can show how it can remain competitive when the smaller upstart stays lean and fast, it's stuck right out of the gate.

I think it may be time Apache itself branches out to a leaner version (with the kitchen sink build available separately) that's as bare-bones as possible with basic functionality that can still be easily extended by modules later.

Of course, it's always good to have other options available. Homogeneity is rather boring.

  For now the main goal is to re-establish the community...

This will be an interesting challenge in an of itself. I'm curious to see how this will pan out and I wish him the best of luck.

mod_python already went into obscurity long ago, that is why this is generating puzzlement.

Apache, while not hipster-compatible, is still very much alive.

> I think it may be time Apache itself branches out to a leaner version (with the kitchen sink build available separately) that's as bare-bones as possible with basic functionality that can still be easily extended by modules later.

Right. Here's a binary size comparison between Apache 2.4.6 and Nginx 1.4.1:

    ~ $ ls -l /usr/sbin/apache2
    -rwxr-xr-x 1 root root 580528 Jul 26 13:23 /usr/sbin/apache2

    ~ $ ls -l /usr/sbin/nginx 
    -rwxr-xr-x 1 root root 661264 May 24 07:42 /usr/sbin/nginx

Apache is totally modular. Going from Apache to Nginx would be a downgrade for me.

When I was referring to "leaner", I was referring to the apparent ease with which Nginx serves while Apache was having difficulty in the same setup (it's quite silly to compare binary sizes). I'm not sure if that makes it not "hipster-compatible" any more than not as performance compatible while running on the same iron and facing the same load.

Also of note, as teilo mentions (https://news.ycombinator.com/item?id=6151215), sometimes you want to decouple the app/scripting engine from the web server.

FYI, current stack is OpenBSD, Nginx, PHP-FPM and Postgres. Does that make us hipsters?

mod_python and its publisher handler is how I got started with web development. Being able to rapidly write web apps in Python was, at the time, a great boon for me. I'm not sure how it fits in with the current state of web app frameworks, but it's nice to see it coming back nonetheless.

mod_python works fine with 2.7, but that might be because Debian/Ubuntu was doing some maintenance out-of-tee (so their patches should definitly be pulled in). To the people who believe it is obsolete, though: mod_wsgi handles only trivial HTTP handling, and is not a reasonable replacement for mod_python, which could be used to plug in to almost any part of the Apache processing pipeline; it is much closer to mod_perl than mod_jk (which feels more like mod_wsgi).

Reply on news.ycombinator.com