Python as replacement for PHP?

[Paul Boddie]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7x7jy0cg4h.fsf at ruckus.brouhaha.com>...
> 
> Yes, but once you add such a module, you're no longer comparing PHP to
> Python.  You're comparing PHP to {Python plus some third party package
> whose stability etc. you have to evaluate from scratch}.  That's an
> issue that people trying to deploy real-world production servers care
> about regardless of how much academics and hobbyists tend to brush it
> off.

So how does it all work when you're deploying something in, say, C or
C++? Those languages don't give you anything above and beyond basic
input/output support and some nice data structures (if you're lucky).
Now, I know that the average Microsoft shop will then state that
they're really developing something with Visual Studio and the usual
Microsoft libraries, and that supposedly gives you the "comfort" of
having Microsoft responsible for everything, but even then you're
likely to run out of road at some point. What kind of pitch do you
make to management then, or has management already attained "buzzword
bingo" by that stage?

> cookedm+news at physics.mcmaster.ca (David M. Cooke) writes:
> > 
> > And hey, if you're choosing a database module, you've got to have
> > already chosen a database -- MySQL, PostgreSQL, SQLite, etc. This is a
> > bigger choice than "how do I talk to it." The Python DB-API makes it
> > relatively easy to write code where the difference in talking to
> > different databases is only in your SQL, and not how you call it.
> 
> No, the DB-API doesn't help you write code at all.  It's the DB-API
> plus it's implementation that lets you write code.  The implementation
> doesn't come with Python, so you have to look elsewhere for it.

So, you're worried about compliance, support, maintenance and so on.
What about stuff like mxODBC? Do you think that there's a real market
opportunity for supported super-distributions of Python, like
ActivePython but with a broader scope?

["complex additional modules maintained by outsiders"]

> Brushing that off and saying "Spyce, CherryPy, etc. are all out there, just
> download them"

Well, that was a suggestion that things exist which potentially do
PHP-like stuff as easily as PHP makes it happen. I can't confirm that,
though, since I'm not really impressed by the PHP/ASP style of
development and not inclined to experiment in depth with those
technologies just to be able to tell someone what they should be using
when they'd get a much better understanding by looking into the matter
themselves.

> is only a matter of degrees better than responding to "Program XYZ is
> full of bugs and crashes all the time and the developers ignore
> everyone" with "that's no big deal, it's open source, you can fix the
> bugs yourself and then it will be fine".

As I'm sure most of us are aware, selecting technologies tends to
involve assessing various factors before dropping those technologies
into our solutions. If "program XYZ" really is that bad, then you
probably don't want to fix it yourself unless there really is nothing
else that comes close to solving the same problems. But at least some
of the Web frameworks can be regarded as being mature enough for real
world use, and the decision to choose one of them can't really be more
involved than that to adopt Python in the first place.

Now, I think you do have a point about the number of technologies and
packages that may need to be combined in order to make a solution, but
I think that this can be addressed by packaging combinations of such
technologies. You see some of this kind of thing with Zope and
derivatives (and even with Apache and PHP, by the way), and it'd be
nice to see the Web-SIG looking into this area, too.

Paul