Discussion:
[newbie] Equivalent to PHP?
(too old to reply)
Gilles
2012-06-12 09:39:50 UTC
Permalink
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
2012-06-12 10:12:55 UTC
Permalink
Post by Gilles
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.
Post by Gilles
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.
Gilles
2012-06-12 10:36:36 UTC
Permalink
On Tue, 12 Jun 2012 12:12:55 +0200, Alain Ketterlin
Post by Alain Ketterlin
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?
D'Arcy Cain
2012-06-12 11:42:56 UTC
Permalink
Post by Gilles
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.
Post by Gilles
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.
--
D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
IM: darcy at Vex.Net
Chris Angelico
2012-06-12 12:01:10 UTC
Permalink
Post by Gilles
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
Gilles
2012-06-12 23:57:23 UTC
Permalink
On Tue, 12 Jun 2012 07:42:56 -0400, D'Arcy Cain <darcy at druid.net>
Post by D'Arcy Cain
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.)?
D'Arcy Cain
2012-06-13 05:52:01 UTC
Permalink
On Tue, 12 Jun 2012 07:42:56 -0400, D'Arcy Cain<darcy at druid.net>
Post by D'Arcy Cain
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.)?
History and laziness I suppose. My biggest project started out as Tcl
and was switched to Python around 1.5. Besides, the boys and girls
at Apache have done a great job. May as well build on that. Even
if I go with a standalone server I will probably put Apache in front
of it for images, style sheets and other static content. I also want
to look into writing Apache modules in Python some day.
--
D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
IM: darcy at Vex.Net
Gilles
2012-06-12 23:58:52 UTC
Permalink
On Tue, 12 Jun 2012 22:01:10 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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?
Steven D'Aprano
2012-06-13 08:29:05 UTC
Permalink
Post by Gilles
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.
--
Steven
Gilles
2012-06-13 09:21:45 UTC
Permalink
On 13 Jun 2012 08:29:05 GMT, Steven D'Aprano
Post by Steven D'Aprano
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.
Grant Edwards
2012-06-13 17:38:25 UTC
Permalink
Post by Steven D'Aprano
Post by Gilles
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/
I just started learning PHP about a week ago in order to do some work
on an embedded device's web site implementation my employer contracted
out. I've done a fair bit of web stuff using CGI in shell, C, and
Python as well as server-side Javascript. I've done a lot of normal
application programming in C and Python and have used a smattering of
other languages (Smalltalk, Scheme, Modula, FORTRAN, BASIC, assembly
for a variety of processors, and even Prolog).

I must say that I agree with the assessement of PHP linked above.
It's not that the language has a design that's not to my taste -- it's
that it has no design at all. It seems to be a mass of miscellaneous
bits and bobs from other languages that have accreted over the years
via some sort of random-walk process.

PHP seems to encourage (if not require) bad practices such as
returning values from functions via global or instance variables.
--
Grant Edwards grant.b.edwards Yow! ! I'm in a very
at clever and adorable INSANE
gmail.com ASYLUM!!
Chris Angelico
2012-06-12 10:18:21 UTC
Permalink
Post by Gilles
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
Octavian Rasnita
2012-06-12 11:28:22 UTC
Permalink
From: "Chris Angelico" <rosuav at gmail.com>
Subject: Re: [newbie] Equivalent to PHP?
Post by Gilles
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?
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
Gilles
2012-06-13 00:00:49 UTC
Permalink
On Tue, 12 Jun 2012 14:28:22 +0300, "Octavian Rasnita"
Post by Octavian Rasnita
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.
Matej Cepl
2012-06-12 14:48:27 UTC
Permalink
Post by Gilles
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).
Post by Gilles
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
2012-06-13 09:25:39 UTC
Permalink
On Tue, 12 Jun 2012 16:48:27 +0200, Matej Cepl <mcepl at redhat.com>
Post by Matej Cepl
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
2012-06-13 09:41:41 UTC
Permalink
Post by Gilles
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
2012-06-13 09:49:00 UTC
Permalink
On Wed, 13 Jun 2012 19:41:41 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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
2012-06-13 10:00:59 UTC
Permalink
Post by Gilles
On Wed, 13 Jun 2012 19:41:41 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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?
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
Gilles
2012-06-13 10:17:12 UTC
Permalink
On Wed, 13 Jun 2012 20:00:59 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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.
Thanks for the longer explanation. With so many frameworks, I'd like
to know what benefits they offer as compared to writing an application
from scratch, and if they do offer obvious benefits, which one to pick
:-/

http://wiki.python.org/moin/WebFrameworks
Prasad, Ramit
2012-06-13 18:01:23 UTC
Permalink
Post by Gilles
Thanks for the longer explanation. With so many frameworks, I'd like
to know what benefits they offer as compared to writing an application
from scratch, and if they do offer obvious benefits, which one to pick
I am going to state up front that I have never tried any of the
frameworks so take my recommendation with a *lot* of salt! :)

I would recommend Django as it seems to scale up nicely and I know
that it has an active community which can be a godsend for getting
help as a "newbie". That being said it does have a bit of a learning
curve compared to some of the lighter frameworks, but not so much
of one as to counteract the advantage of scalability. Again, this
is all based on opinions that I have read (and remember) and not
on any facts.

Maybe this article will help you http://www.infoworld.com/d/application-development/pillars-python-six-python-web-frameworks-compared-169442
The comments on /. should round out anything missing from the article (I hope)
http://developers.slashdot.org/story/11/08/10/2111203/six-python-web-frameworks-compared


Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Gilles
2012-06-13 20:45:45 UTC
Permalink
On Wed, 13 Jun 2012 18:01:23 +0000, "Prasad, Ramit"
Post by Prasad, Ramit
Maybe this article will help you http://www.infoworld.com/d/application-development/pillars-python-six-python-web-frameworks-compared-169442
The comments on /. should round out anything missing from the article (I hope)
http://developers.slashdot.org/story/11/08/10/2111203/six-python-web-frameworks-compared
Thanks for the links.
Steven D'Aprano
2012-06-13 22:16:51 UTC
Permalink
Thanks for the longer explanation. With so many frameworks, I'd like to
know what benefits they offer as compared to writing an application from
scratch
Surely the obvious answer is that a framework offers the benefit that you
don't have to write the application from scratch.

Why write in Python instead of creating your application from scratch
written in assembly? Because you get the benefit of 40+ years of
collective programming language design experience, 10+ years of
collective Python experience, tens or hundreds of thousands of lines of
carefully debugged and tuned code, and a large community of users with
experience in the language, books, training courses, etc. whom you can
call on for advice (free or paid consulting) and as a pool of would-be
employees if you need to hire developers.

You wouldn't (or at least shouldn't) even *consider* writing your own
language unless you had really good reason, and no other existing
language would do.

Web frameworks are similar: you get tens or hundreds of thousands of
lines of carefully debugged and tuned code, and a community of users,
books, etc. Unless your needs are minuscule, writing your application
from scratch will end up duplicating much of the framework, only (let's
be realistic here) badly. By the time your application is as stable,
debugged and tuned as as existing framework, you will have spent probably
in excess of ten person-years.

At which point, you have a community of one, yourself. (Or possibly you
and a handful of your fellow project members.)

For anything but the smallest web applications, where no framework is
necessary, and the very largest, if no existing framework will do, why
would you even consider reinventing the wheel?
--
Steven
Gilles
2012-06-13 22:44:23 UTC
Permalink
On 13 Jun 2012 22:16:51 GMT, Steven D'Aprano
Post by Steven D'Aprano
Surely the obvious answer is that a framework offers the benefit that you
don't have to write the application from scratch.
Yes, but between receiving the query and sending the response, what
features do frameworks offer that I'd have to write myself otherwise?
Steven D'Aprano
2012-06-14 00:08:57 UTC
Permalink
Post by Gilles
On 13 Jun 2012 22:16:51 GMT, Steven D'Aprano
Post by Steven D'Aprano
Surely the obvious answer is that a framework offers the benefit that
you don't have to write the application from scratch.
Yes, but between receiving the query and sending the response, what
features do frameworks offer that I'd have to write myself otherwise?
What, google broken for you? *wink*

Copied and pasted from http://cherrypy.org/

FEATURES
A fast, HTTP/1.1-compliant, WSGI thread-pooled webserver.
Easy to run multiple HTTP servers (e.g. on multiple ports) at once.
A powerful configuration system for developers and deployers alike.
A flexible plugin system.
Built-in tools for caching, encoding, sessions, authorization, static
content, and many more.
Swappable and customizable...everything.
Built-in profiling, coverage, and testing support.
Runs on Python 2.5+, 3.1+, Jython and Android.


Plus you have a whole community of people working on the framework,
fixing bugs and writing documentation, and you don't have to pay them a
cent.

http://duckduckgo.com/?q=cherrypy+features

Repeat as needed for any other framework you are interested in.

Essentially, using a framework means you get to concentrate on the actual
problem your application is meant to solve instead of spending most of
your time worrying about building the infrastructure (the framework!) to
hold your application.
--
Steven
Tim Chase
2012-06-14 00:03:29 UTC
Permalink
Post by Gilles
On 13 Jun 2012 22:16:51 GMT, Steven D'Aprano
Post by Steven D'Aprano
Surely the obvious answer is that a framework offers the benefit that you
don't have to write the application from scratch.
Yes, but between receiving the query and sending the response, what
features do frameworks offer that I'd have to write myself otherwise?
Let's see

- CRSF protection
- keeping things DRY
- templating (or you could use many others)
- user management
- administrative interface
- database creation/introspection
- i18n
- an ecosystem of pluggable add-on apps
- URL routing
- view decorators
- easily swappable back-ends
- active development across multiple lines of business
- GIS support
- abstracted ORM (or you could use SQLObject or its kin) to allow
you mobility between DB back-ends should you want to

That's just my off-the-top-of-my-head list of things that you'd have
to come up with that Django happens to give you out-of-the-box.

-tkc
Gilles
2012-06-14 10:53:27 UTC
Permalink
On Wed, 13 Jun 2012 19:03:29 -0500, Tim Chase
Post by Tim Chase
That's just my off-the-top-of-my-head list of things that you'd have
to come up with that Django happens to give you out-of-the-box.
Thanks much. So the next step will have to find a framework that's
right for a given application.
Gilles
2012-06-12 23:59:26 UTC
Permalink
On Tue, 12 Jun 2012 20:18:21 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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?
Chris Angelico
2012-06-13 00:19:29 UTC
Permalink
Post by Gilles
On Tue, 12 Jun 2012 20:18:21 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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?
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
Gilles
2012-06-13 09:22:55 UTC
Permalink
On Wed, 13 Jun 2012 10:19:29 +1000, Chris Angelico <rosuav at gmail.com>
Post by Chris Angelico
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.
Christian Heimes
2012-06-13 15:27:21 UTC
Permalink
Post by Gilles
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).
A long running process has lots of benefits that makes design and
development easier and makes your app faster.

* Don't underestimate the costs of process creation. It doesn't scale
unless you fork() childs which is more complex and still doesn't scale
as well as a long running process.

* you can do all costly and time consuming operations on startup like
loading all configuration files and databases like i18n stuff.

* performance tweaks like database connection pool works only with a
long running process.

* in-process caching is usually easier to implement and faster. In some
cases only in-process works.

* you can have background tasks without the requirement of an outside
service like cron + wget.

* async server based on a select()-like reactor are only possible when a
single process handles the incoming connections.


A long running process is more powerful and the 'enterprise' way of
doing it right. All important and large scale Python and Java solutions
are using long running processes instead of a CGI-like model.

PHP's way is a poor man's solution to compensate for bad design and
memory holes. PHP's ancestor PHTML still bleeds through and makes you
suffer for mistakes of the past.

Christian
Gilles
2012-06-13 20:48:07 UTC
Permalink
On Wed, 13 Jun 2012 17:27:21 +0200, Christian Heimes
Post by Christian Heimes
A long running process has lots of benefits that makes design and
development easier and makes your app faster.
Thanks much for the infos. Makes you wonder why commercial companies
still choose PHP to write their web site.
Christian Heimes
2012-06-13 21:16:31 UTC
Permalink
Post by Gilles
On Wed, 13 Jun 2012 17:27:21 +0200, Christian Heimes
Post by Christian Heimes
A long running process has lots of benefits that makes design and
development easier and makes your app faster.
Thanks much for the infos. Makes you wonder why commercial companies
still choose PHP to write their web site.
PHP was developed for non-developers. (see
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ).
It's much easier and also cheaper to find bad coders and non-developers
than code people. The outcome is bad performance and lots of security
issues.

Christian
Gilles
2012-06-13 22:45:21 UTC
Permalink
On Wed, 13 Jun 2012 23:16:31 +0200, Christian Heimes
Post by Christian Heimes
PHP was developed for non-developers. (see
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ).
It's much easier and also cheaper to find bad coders and non-developers
than code people. The outcome is bad performance and lots of security
issues.
And as to why Facebook chose PHP...
Prasad, Ramit
2012-06-13 23:12:37 UTC
Permalink
Post by Gilles
Post by Christian Heimes
PHP was developed for non-developers. (see
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ).
It's much easier and also cheaper to find bad coders and non-developers
than code people. The outcome is bad performance and lots of security
issues.
And as to why Facebook chose PHP...
You are not Facebook (at least yet).

They also choose to transform PHP into C++ for performance reasons. Not
something the average large website would want to do.
http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-runtime.aspx
http://www.datacenterknowledge.com/the-facebook-data-center-faq-page-2/


The real question is would they use it again if they were to start over?
http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choose-Python-for-its-development


These decisions are influenced by a multitude of factors
1. familiarity/popularity of a framework
2. support
3. what someone thinks is "best" for specifications
4. cost
Notice only 1 of those factors was what was actually "best".


Also remember you asked this on a *Python* mailing list. I am sure you
will get different responses on a PHP mailing list.

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Gilles
2012-06-13 23:36:12 UTC
Permalink
On Wed, 13 Jun 2012 23:12:37 +0000, "Prasad, Ramit"
Post by Prasad, Ramit
You are not Facebook (at least yet).
Indeed, but with so much criticism about PHP, it's odd that they would
still choose it.

Anyway, thanks much for the infos. I'll look at the web frameworks and
how to connect the Python app to a front-end web server.
Prasad, Ramit
2012-06-14 00:25:02 UTC
Permalink
Post by Gilles
Indeed, but with so much criticism about PHP, it's odd that they would
still choose it.
Could be a familiarity/ease issue as it was originally started by a
college student (and college students seldom have meaningful real
world experience) before it exploded in size. Also do not forget
that it was developed nearly a decade ago and technology has
changed (hopefully improved) a lot since then.
Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Terry Reedy
2012-06-14 03:38:18 UTC
Permalink
Post by Gilles
On Wed, 13 Jun 2012 23:16:31 +0200, Christian Heimes
Post by Christian Heimes
PHP was developed for non-developers. (see
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ).
It's much easier and also cheaper to find bad coders and non-developers
than code people. The outcome is bad performance and lots of security
issues.
And as to why Facebook chose PHP...
*When* did 'Facebook' choose it? (My brief search did not reveal this.)
Facebook started as a quick hack (Facemash) by student Mark Zuckerberg
in Nov 2003. If he used PHP (1995) then or for his next site or for the
initial Facebook a few months later, that would suggest an answer.
--
Terry Jan Reedy
Gilles
2012-06-21 12:24:45 UTC
Permalink
Post by Gilles
I'm an amateur programmer, and would like to know what the main
options are to build web applications in Python instead of PHP.
When I need to host my Python application (preferably in Europe since
my users will be located there), what are the options?

Do Python hosters provide a VM so that it's just like a remote Linux
server where I'm free to install whatever I want, or do they force
users to use specific versions of Python and specific frameworks eg.
Django?

Thank you.
Paul Rubin
2012-06-21 17:44:08 UTC
Permalink
Post by Gilles
Do Python hosters provide a VM so that it's just like a remote Linux
server where I'm free to install whatever I want, or do they force
users to use specific versions of Python and specific frameworks eg.
Django?
There are both kinds. The first kind is called a Virtual Private Server
(VPS). The second kind is called shared hosting. VPS is very flexible
but shared hosting can be cheaper, and easier to use if you have no
sysadmin skills. I'm assuming you don't have enough workload to want to
rent a physical server (sometimes called a "dedi", short for dedicated
server) or colo (colocation, meaning you buy your own hardware and
install it in a rack slot that you rent at the data center).


OVH (www.ovh.com/fr) is the biggest French hosting place and they have
all three types of service, I think. Their low cost branch is
www.kimsufi.fr which has extremely attractive prices. I have heard
mixed things about them: you get a lot of resources for the money, but
that they can be hard to deal with in various ways. So it sounds not
great but not terrible. Kimsufi dedis are cheaper than anything
comparable that we can get in the USA, so I have been interested in
renting one for some of my own stuff, but I haven't pursued this yet.

www.webhostingtalk.com and www.lowendbox.com are good places to research
this sort of thing. lowendbox.com is specifically for cheap VPS's.
Gilles
2012-06-21 21:58:02 UTC
Permalink
On Thu, 21 Jun 2012 10:44:08 -0700, Paul Rubin
Post by Paul Rubin
There are both kinds. The first kind is called a Virtual Private Server
(VPS). The second kind is called shared hosting.
Thanks much for the infos.

Continue reading on narkive:
Loading...