[newbie] Equivalent to PHP?

[Gilles]

Hello

I'm an amateur programmer, and would like to know what the main
options are to build web applications in Python instead of PHP.

I notice that Python-based solutions are usually built as long-running
processes with their own web server (or can run in the back with eg.
Nginx and be reached through eg. FastCGI/WSGI ) while PHP is simply a
language to write scripts and requires a web server (short running
processes).

Since web scripts are usually very short anyway (user sends query,
server handles request, sends response, and closes the port) because
the user is waiting and browsers usually give up after 30 seconds
anyway... why did Python solutions go for long-running processes while
PHP was built from the start as short-running processes?

Thank you.

 

[Alain Ketterlin]

I notice that Python-based solutions are usually built as long-running
processes with their own web server (or can run in the back with eg.
Nginx and be reached through eg. FastCGI/WSGI ) while PHP is simply a
language to write scripts and requires a web server (short running
processes).

It's an artefact of the server infrastructure, there is no rule here.
Any solution used with one language could be used with the other.

Since web scripts are usually very short anyway (user sends query,
server handles request, sends response, and closes the port) because
the user is waiting and browsers usually give up after 30 seconds
anyway... why did Python solutions go for long-running processes while
PHP was built from the start as short-running processes?

You misunderstand the problem here. It's not about the duration of the
actions, it's about the latency it takes to read/parse/execute the
script. HTTP is stateless anyway, so if the same "interpreter" handles
several requests, what you save by keeping the interpreter alive is the
load/parse phase. If you relaunch an interpreter for every HTTP request,
you pay the same price again and again for something which is not even
related to your scripts' execution.

-- Alain.

 

[Chris Angelico]

Since web scripts are usually very short anyway (user sends query,
server handles request, sends response, and closes the port) because
the user is waiting and browsers usually give up after 30 seconds
anyway... why did Python solutions go for long-running processes while
PHP was built from the start as short-running processes?

Think of it as Apache + PHP versus Python. Apache keeps running, it's
only your PHP script that starts and stops. With a long-running
process, you keep everything all in together, which IMHO is simpler
and better.

ChrisA

 

[Gilles]

You misunderstand the problem here. It's not about the duration of the
actions, it's about the latency it takes to read/parse/execute the
script. HTTP is stateless anyway, so if the same "interpreter" handles
several requests, what you save by keeping the interpreter alive is the
load/parse phase. If you relaunch an interpreter for every HTTP request,
you pay the same price again and again for something which is not even
related to your scripts' execution.

Thanks for the input.

But I read that PHP-based heavy-duty web servers compile the scripts
once and keep them in a cache, so they don't have to be
read/parsed/executed with each new query.

In that case, what is the benefit of using a long-running process in
Python?

I enjoy writing scripts in Python much more than PHP, but with so many
sites written in PHP, I need to know what major benefits there are in
choosing Python (or Ruby, ie. not PHP).

Apparently, very few people use Python à la PHP, ie. Python code
embedded in web pages?

 

[Octavian Rasnita]

From: "Chris Angelico" <[email protected]>
Subject: Re: [newbie] Equivalent to PHP?



Perl, Ruby, Python and PHP also can do the same thing.

You can use a persistent program which is loaded/parsed/compiled once and kept into memory and it will just answer the requests, or you can create a program which is loaded/parsed/compiled on each request.

The first way is much better for performance reasons but it consumes much more memory and it is more complicated, because the programs can have memory leaks (they will consume more and more memory after a long period), while the second way is more simple to do, but the performance is not great.

Most PHP programs are done using the second way, because it is much simple to do and it is much simple to configure the environment for it, and most of the free web hosting sites that offer PHP support don't offer something better.
And... most of the sites don't need a very good performance, because they usually don't have millions visitors per day.

Also, most of the sites made in PHP use low level programs using only what the default PHP distribution installed on the server offers, so no web frameworks, or form managers, or templating systems or many other modules that can do a part of the work.
The PHP distribution has compiled C programs which run pretty fast, while loading/parsing/compiling a lot of other modules made in Ruby/Perl/Python/PHP would decrease the performance, so a persistent environment is usually required in case those modules are used. And usually Python and Perl and Ruby programs use a lot of modules because for these languages there are a lot of modules available that can do a lot of things for free, while for PHP there are much fewer, and even if there are, (because there are templating systems and web frameworks for PHP also), they are much seldomly used, because those who choose to use a broken language like PHP, usually choose it not only for its main advantage regarding the easiness of deployment, but choose it because it is much more simple and easy to learn, and they usually don't like to learn a lot of other modules.
Otherwise... if you want you can also create a web app using PHP and CodeIgniter web framework and run it with fastcgi...

Octavian

 

[D'Arcy Cain]

I enjoy writing scripts in Python much more than PHP, but with so many
sites written in PHP, I need to know what major benefits there are in
choosing Python (or Ruby, ie. not PHP).

I think that you just answered your own question in the first line of
that paragraph. With computers running so fast and memory and disk
being so cheap, the only decision left for most applications is what
language do you prefer. Python wins because it is so nice to work
with. It's clean and you don't have to deal with the daily security
holes of PHP.

Apparently, very few people use Python à la PHP, ie. Python code
embedded in web pages?

I guess I am in the minority then. I do plan to turn one of my larger
projects into a standalone web server some day but so far writing
simple Python CGI scripts has served me fine. I even do some embedding
by using server side scripting.

 

[Chris Angelico]

Thanks for the input.

But I read that PHP-based heavy-duty web servers compile the scripts
once and keep them in a cache, so they don't have to be
read/parsed/executed with each new query.

In that case, what is the benefit of using a long-running process in
Python?

Apache's mod_php partially evens out the difference, but not
completely, and of course, it's perfectly possible to write a dispatch
loop in PHP, as Octavian said.

Python is a far better language than PHP, I would strongly recommend
making use of it if you can.

ChrisA

 

[Matej Cepl]

I notice that Python-based solutions are usually built as long-running
processes with their own web server (or can run in the back with eg.
Nginx and be reached through eg. FastCGI/WSGI ) while PHP is simply a
language to write scripts and requires a web server (short running
processes).

I don't think it is a proper description of the situation (please,
somebody correct my mistakes, I am not 100% sure about it myself). WSGI
applications (which is basically all web applications in Python) could
run in the hosted servers (using for example mod_wsgi for Apache), and I
would expect that it is the situation with most production uses.

From the programmer's point of view WSGI application (read
http://en.wikipedia.org/wiki/Wsgi) is just one script which takes HTTP
request on input and generates HTTP Response on output, so it is
actually quite simple. And actually quite similar to what JSGI, PSGI,
and Rake do (I am not sure who was first whether WSGI or Rake).

anyway... why did Python solutions go for long-running processes while
PHP was built from the start as short-running processes?

It is all about caching ... I am not sure how it is done exactly, but I
would expect for example mod_wsgi to cache parsed Python script in
memory as well.

Matěj

 

[Gilles]

I guess I am in the minority then. I do plan to turn one of my larger
projects into a standalone web server some day but so far writing
simple Python CGI scripts has served me fine. I even do some embedding
by using server side scripting.

Out of curiosity, why did you choose to write CGI scripts or embedded
server-side scripting while standalone web servers are usually
presented as _the_ solution for Python (Django, Pylons, etc.)?

 

[Gilles]

Apache's mod_php partially evens out the difference, but not
completely, and of course, it's perfectly possible to write a dispatch
loop in PHP, as Octavian said.

It looks like mod_php and equivalents for web servers other than
Apache are anecdotal compared to solutions based on standalone web
servers. Is that the case? Why is that?

 

[Gilles]

Think of it as Apache + PHP versus Python. Apache keeps running, it's
only your PHP script that starts and stops. With a long-running
process, you keep everything all in together, which IMHO is simpler
and better.

Why is a long-running process better?

 

[Gilles]

Otherwise... if you want you can also create a web app using PHP and CodeIgniter web framework and run it with fastcgi...

Thanks for the infos.

 

[Chris Angelico]

Why is a long-running process better?

It's far simpler to manage, it retains running state, and is easily
enough encapsulated. It's the non-magic way of doing things. Also, it
plays very nicely with the MUD style of process, which is something I
do a lot with Pike. Plus, if you manage it right, you have a guarantee
that you can never be in a half-updated state - that's somewhat tricky
when you have inter-dependencies in PHP code and the file system
itself manages things. What happens if a request comes in while you're
half-way through uploading new code to the server? By default, you
could use half old code and half new code. Keeping everything in
memory makes it easier to prevent that.

ChrisA

 

[Steven D'Aprano]

I enjoy writing scripts in Python much more than PHP, but with so many
sites written in PHP, I need to know what major benefits there are in
choosing Python (or Ruby, ie. not PHP).

The main benefit is that they are not PHP.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

and especially lack PHP's security vulnerabilities.

 

[Gilles]

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

and especially lack PHP's security vulnerabilities.

Thanks for the link.

 

[Gilles]

It's far simpler to manage, it retains running state, and is easily
enough encapsulated. It's the non-magic way of doing things. Also, it
plays very nicely with the MUD style of process, which is something I
do a lot with Pike. Plus, if you manage it right, you have a guarantee
that you can never be in a half-updated state - that's somewhat tricky
when you have inter-dependencies in PHP code and the file system
itself manages things. What happens if a request comes in while you're
half-way through uploading new code to the server? By default, you
could use half old code and half new code. Keeping everything in
memory makes it easier to prevent that.

Thanks for the input.

 

[Gilles]

I don't think it is a proper description of the situation (please,
somebody correct my mistakes, I am not 100% sure about it myself). WSGI
applications (which is basically all web applications in Python) could
run in the hosted servers (using for example mod_wsgi for Apache), and I
would expect that it is the situation with most production uses.

I have a couple more questions:

1. Today what is the recommended way to connect a long-running Python
web application with a web server running in the front? FastCGI? WSGI?
Other?

2. Which solid web server is recommended to connect to Python web
applications in the back?

3. What Python web framework would you recommend to get started, and
possibly more heavy duty framework in case I need something bigger
later?

Thank you.

 

[Chris Angelico]

I have a couple more questions:

1. Today what is the recommended way to connect a long-running Python
web application with a web server running in the front? FastCGI? WSGI?
Other?

2. Which solid web server is recommended to connect to Python web
applications in the back?

3. What Python web framework would you recommend to get started, and
possibly more heavy duty framework in case I need something bigger
later?

There are quite a few Python web frameworks, but I've never used any.
What I have done, though, is subclass
BaseHTTPServer.BaseHTTPRequestHandler, override do_GET(self), and run
a core loop with a single line of code (well, there's a little more so
the server can be halted cleanly with Ctrl-C, but close enough). And
it runs beautifully on Windows and Linux, and would probably run on
any other platform with a Python, if anyone felt like trying.it.
However, there are times when you need a little more organization, and
I don't know how easy it is to minimize downtime when you need to
update code (with this particular example, I just restart it and have
a couple of minutes' outage, which isn't an issue).

For high-availability servers, I can't speak for Python, as I've never
done that there; but it seems likely that there's good facilities. My
personal preference is Pike, but that's off-topic for this list.
But the simple answer for simple tasks is: Don't bother with
frameworks, run an HTTP server.

Chris Angelico

 

[Gilles]

For high-availability servers, I can't speak for Python, as I've never
done that there; but it seems likely that there's good facilities. My
personal preference is Pike, but that's off-topic for this list.
But the simple answer for simple tasks is: Don't bother with
frameworks, run an HTTP server.

Thanks. What do you mean with "Don't bother with frameworks, run an
HTTP server"? Subclassing BaseHTTPServer?

 

[Chris Angelico]

Thanks. What do you mean with "Don't bother with frameworks, run an
HTTP server"? Subclassing BaseHTTPServer?

Apache is a web server, by which one technically means an HTTP server.
HTTP is the protocol (HyperText Transfer Protocol) by which web
servers and browsers communicate. Basically, you listen on a TCP/IP
socket, usually port 80, and respond to requests.

One way to achieve that is to let somebody else do the whole
listen-on-80 bit and then call upon you to generate a block of text.
That's what happens with Apache and PHP - your PHP script doesn't
think about sockets, listening, and so on, it just gets a request and
deals with it.

The other obvious option is to write your own code using the basic BSD
socket functions, and do the whole job yourself. That's a good thing
to do once in a while, just to get to know how it all fits together,
but unless you're working in C, there's no particular reason to go to
that much hassle.

Half way in between is where BaseHTTPServer puts you. All the
grunt-work is done for you, but your program is still 100% in control.
You call on somebody else's code (the Python standard library) to
handle all the socket basics, and your code gets called to generate a
page. But you can do more than just generate a page, if you so desire.

Most high level languages probably have some sort of HTTP server
available. Some make it trivially easy to plug some code in and start
serving. Python is advertised as "batteries included", and one of its
packets of batteries is a fairly full-featured set of internet
protocol handlers.

ChrisA