Python as replacement for PHP?

[R. Rajesh Jeba Anbiah]

[Well, this time I have decided to troll -- all because of prolong
irritating ignorant posts/crossposts. And, this is intentional
crosspost.]

When it comes to dynamic, DB driven sites, PHP is the only way to go.
Python is not even close to being suited for this task. PHP claims to be
a general-purpose language, but I do not know anyone who uses it for
anything other than dynamic Web programming.

Like everyone else who has replied, I seriously question how much
experience you have with the multitude of Python web environments
available. As an objective, point-by-point look at your specific
example of somewhere PHP is strong, here's my reply:

[PS: I still use PHP regularly, albeit only for quick unimportant
hacks that won't exist in 6 months]

So.. you don't have any important works :-/

- Nearly all the PHP code I have seen (including various large web
sites) fails to handle error conditions, and will run amok given a
down DB server, bad filesystem permissions, or bad inputs. I have had
personal experience, on more than one occasion, of an error condition
in someone else's PHP code causing a large amount of damage to a
dataset.

Good news. Well done PHP!

- The equivalent Python code will almost never do that. Thanks to the
religious throwing of exceptions, well written standard libraries, DB
adaptors, and so on, the worst Python code has a MUCH better chance of
getting stopped in it's tracks just as a fault occurs.

py> open("/tmp/foo","w").write(123)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: argument 1 must be string or read-only character buffer,
not int


[22:15:14] [cape:4:dw]$ php4 <<e

<? fwrite(fopen('foo','w'), 123); ?>
e

[22:15:16] [cape:5:dw]$ cat /tmp/foo
[22:15:17] [cape:6:dw]$

Can you tell me exactly what the PHP fwrite function did when I passed
it an integer? Can you tell me how many PHP programmers test
"(strlen($to_write) == fwrite($fp, $to_write))"?

Ok...understand. idiot-proof?

- In the specific instance of database connectivity, Python is far
superior, in terms of intuitiveness, security, safety, and so on.
Python database APIs are built in a way that protects you by default.

Perhaps, idiots' own language?

- PHP provides no intuitive default support for many common DB
operations. Compare the following messes:

py> l = MySQLdb.connect()
py> c = l.cursor()
py> user_input = "%t%"
py> match_count = c.execute("SHOW DATABASES LIKE %s", ( user_input
))
py> print match_count, "matches:", [ x for x, in c ]
1 matches: ['test']


<? $s = mysql_connect();
$user_input = "%t%";
$query_sql = sprintf("SHOW DATABASES LIKE \"%s\"",
mysql_real_escape_string($user_input, $s));
$query = mysql_query($query_sql, $s);
$matches = array();
while ($row = mysql_fetch_array($query, MYSQL_NUM)) $matches[]=
$row[0];
echo sizeof($matches), " matches: ", var_export($matches, true);


Tell me, of these two popular examples of bad code in both languages,
which is the more intuitive to read, which is the more elegant to keep
secure, and which would you prefer to be reading, and modifying in 18
months time? [In this case, which was the quicker to create? The
Python example. The PHP counterpart has a syntax error somewhere, I
care not where.]

How many different ways can you dream up the same functionality in the
PHP example? (mysql_escape_string, <random_db_api>, etc.)

How likely is it that the developer you hire to take over development
of either snippet of code will understand the concept behind it? I
can't even think of another way of doing database query in Python,
without using the low-level interfaces, which is just insane.

We could bring the PHP ADODB, or many of the other numerous PHP APIs
for DB connectivity into the picture, but which of these are the
obvious choice, and officially endorsed?

How easy is it to improve on both these examples to add proper error
handling? Again, Python wins hands down for elegance, conciseness, and
obviousness.

Yes, agreed. Idiots' language.

- Python has a religious following of thousands, many of whom found
freedom through it's restraint, unified path, and downright beauty.
The result is a long tradition of structured, well written code.
Python has roots in academia, and started life with a defined purpose,
and a BDFL who knew what he was doing.

- PHP, "the web designer's ideal first language", started out life as
"a collection of perl scripts" (that says it all really), then ported
to C, then hacked and added to until it was the great swiss army
monolith that it is today. PHP has never had a clear, publically
documented development path, or indeed any form of structure or
organisation, past the menu system of PHP.net

LOL! Joke of the millennium.

PHP developers tend to have started life using Dreamweaver, happy to
accept the first solution to a problem that comes their way, and care
little about technical merit. Every person (including at the time,
myself) who I know that uses, or used PHP, did so because it allowed
them to make things look beautiful and dynamic very quickly.

Yet another good joke.

- Python gurus, when asked how to make something work, will often
appear nasty and horrible, telling you you're doing entirely the wrong
thing and you should go back to the drawing board. Much like the hot
sting from a smack of a father's hand, this is good, not bad. It is
there to direct and discipline you, and improve the way you think.

- PHP gurus tend to be experienced web developers, they'll be able to
look flash and give you an answer on the spot, but that answer will
only further lead to the demise of any structure your coding ever had.

Huh??

- Python tends to be slow, but slow compared to what? The laptop I
type this message on has a 2ghz processor. It cost less than £1000. It
is the cheapest laptop money can buy in the UK. I run Python scripts
on multi-gigabyte datasets on a daily basis on this machine. I have
never considered the scripts to be 'slow'.

- PHP is very light on CPU, memory, and so on. I earn a modest amount
for a 20 year old, even by Northern Ireland standards. I can't see how
I would ever need to resort to PHP because I couldn't afford the
hardware to run a complex Python-based site intended for viewing by
thousands.


Personally, I find the average PHP codebase to be akin to a television
station such as MTV: well presented, streamlined, professional
looking, but in terms of content, nothing but meaningless, mindless
shite. On the other hand, reading certain Python code is more like
reading a beautifully typeset hardback novel: black and white - ugly
to some, but functional, educational, structured, meaningful, etc,
etc.

What interests you more - earning money through thoughtless,
effortlessly produced rant-syntax that no-one will ever want to look
at again, or the daily challenge to produce something that will
perfectly fulfill it's intended function, at the cost of a little
time, a little brainpower, and a little discipline.

I could go on, but I think these points alone are the main reasons I
use Python. At the cost only of speed, it protects me, teaches me,
profits me, and inspires me to continue being the professional geek
that I am.

comp.lang.php is not the right place for you to show your
stupidity. You should consider stripping headers as many other PHP
ignorants (<http://groups.google.com/[email protected]>)
did before throwing your thoughts.

HTH. HAND.

 

[Ville Vainio]

R> [Well, this time I have decided to troll -- all because of

Ok, I get the drift.


R> Ok...understand. idiot-proof?

So type safety means idiot-proofing? What do you gain by allowing
obvious errors to be silently ignored?

When a third-party library returns an object you didn't expect in
writing your code, you would surely want to know? I do.

R> Perhaps, idiots' own language?

You still realize this is crossposted to c.l.py, right? Kindergarten
tactics don't erally work all that well here. Some observer of this
discussion might draw some conclusions about which one of the
languages is the "idiot's own language"...

R> Yes, agreed. Idiots' language.

Yes, elegance is indeed for idiots. True r0xx0r h4xxx0rz use PHP,
because it's so cryptic and looks cool because n00bs can't understand
it.

R> comp.lang.php is not the right place for you to show your
R> stupidity. You should consider stripping headers as many other

Neither is c.l.py. Actually, we have remarkably few idiots in c.l.py.

I don't know why I'm replying - your post kinda speaks for itself.

 

[Phil Roberts]

With total disregard for any kind of safety measures
(e-mail address removed) (David M. Wilson) leapt forth and
uttered:

- Python gurus, when asked how to make something work, will
often appear nasty and horrible, telling you you're doing
entirely the wrong thing and you should go back to the drawing
board. Much like the hot sting from a smack of a father's hand,
this is good, not bad. It is there to direct and discipline you,
and improve the way you think.

- PHP gurus tend to be experienced web developers, they'll be
able to look flash and give you an answer on the spot, but that
answer will only further lead to the demise of any structure
your coding ever had.

So, by your logic Python developers tend to be self-important
assholes whereas PHP developers will give you an answer, but they
expect you to have enough knowledge to implement it correctly?

 

[has]

PHP's web environment are
database integration right there for you the moment you install PHP.

Ancient proverb say: One man's "database integration" is another's
"tight coupling".

 

[Paul Boddie]

The very existence of a "multitude" of Python web environments is a
serious shortcoming of Python as a PHP replacement.

As a PHP replacement, I'd argue that a number of existing frameworks
are good and obvious enough - cue developer adverts for Spyce,
CherryPy, etc. ;-) With the PSP support in mod_python, I'd argue that
the bar has been lowered further. But in the short to medium term,
expect better application portability between frameworks - the need to
run various popular applications in different environments is making
itself increasingly evident.

[...]

That's precisely the situation Python is in now!

Really? At the fundamental level, the DB-API is pretty well
standardised, and there's a collection of well-written modules that
mostly adhere to it. Object-relational mappings aren't standardised,
but I haven't seen any widely-followed standards implemented in any
technology.

[...]

The site that I worked on spent TWO MILLION U.S. DOLLARS on its web
server hardware. OK, it used Java servlets that are even slower than
Python, but you have to understand that there's a point after which
you can no longer pretend that hardware is free.

Yes, but then those responsible for religiously stipulating "full fat"
application/database server technologies tend to have big budgets
anyway. There's a point after which you could be horrified about the
money being spent on hardware, but hopefully it isn't your budget
draining away at that point.

Paul

 

[R. Rajesh Jeba Anbiah]

R> [Well, this time I have decided to troll -- all because of

Ok, I get the drift.

Mr.Ville Vainio, I really impressed by your detector and the way
you snip others' comments. Thanks.

R> Ok...understand. idiot-proof?

So type safety means idiot-proofing? What do you gain by allowing
obvious errors to be silently ignored?

When a third-party library returns an object you didn't expect in
writing your code, you would surely want to know? I do.

If you do *programming* without knowing what to pass to a function
or what a function returns, you're a complete idiot as a idiot can be.
Moreover, if you take it as an argument against PHP, you're yet
another ignorant and obviously you don't have any rights to speak
about PHP nor anything.

R> Perhaps, idiots' own language?

You still realize this is crossposted to c.l.py, right? Kindergarten
tactics don't erally work all that well here.

Huh?? So..here, where you stand??

Some observer of this
discussion might draw some conclusions about which one of the
languages is the "idiot's own language"...

Yes, people with functioning brain may already conculded that when
you posted your previous message itself.

R> Yes, agreed. Idiots' language.

Yes, elegance is indeed for idiots. True r0xx0r h4xxx0rz use PHP,
because it's so cryptic and looks cool because n00bs can't understand
it.

If you post these jottings to the PHP ignorants, they may even
build a statue for you. But, I guess, it is hard to get that kind of
ignorants.

R> comp.lang.php is not the right place for you to show your
R> stupidity. You should consider stripping headers as many other

Neither is c.l.py. Actually, we have remarkably few idiots in c.l.py.

No problem. I could see here itself

I don't know why I'm replying - your post kinda speaks for itself.

Thanks Mr.Ville Vainio for sparing your time to provide brilliant
comments.

HTH. HAND.

--
From comp.lang.php
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
If you live in USA, please support John Edwards.
Email: rrjanbiah-at-Y!com

 

[Ville Vainio]

R> If you do *programming* without knowing what to pass to a
R> function or what a function returns, you're a complete idiot as
R> a idiot can be. Moreover, if you take it as an argument

Occasionally, in absence of static typing, you might accidentally call
a function using a return value of another function as an argument and
they are not compatible. W/ python you notice it immediately; with PHP
or Perl your program starts behaving weirdly (if you don't check
return values that is) and you can't pinpoint exactly what went
wrong. This is what makes people run to statically typed languages,
believing that all dynamic typing is shoddy like this.

R> against PHP, you're yet another ignorant and obviously you
R> don't have any rights to speak about PHP nor anything.

I wasn't really talking about PHP, but the approach you took to attack
the arguments of OP (arguments which I agree w/ BTW, but that's
another story).

R> Yes, people with functioning brain may already conculded that
R> when you posted your previous message itself.

Previous message? The one you were replying to was the first I posted
to this thread.

R> No problem. I could see here itself
R> <http://groups.google.com/[email protected]>

Great.

 

[Peter Maas]

If you do *programming* without knowing what to pass to a
> function
or what a function returns, you're a complete idiot as a idiot can be.
Moreover, if you take it as an argument against PHP, you're yet
another ignorant and obviously you don't have any rights to speak
about PHP nor anything.

Excuse me ... Does the life of your children depend on a friendly.
reception of PHP? I'm just searching a reason for your aggressiveness.
Never saw that in c.l.py.

Mit freundlichen Gruessen,

Peter Maas

 

[Paul Rubin]

As a PHP replacement, I'd argue that a number of existing frameworks
are good and obvious enough - cue developer adverts for Spyce,
CherryPy, etc. ;-)

While those are nice pieces of code, they're not in the official
distribution, which means they're a separate point of failure for
maintenance, security auditing, and so forth. I.e., if you're trying
to pitch Python for some project and convince management that it's
secure and adequately maintained, you now have to separately make the
exact same pitch for Spyce. And you then have to pick out a database
interface layer and make another separate pitch for THAT. With PHP,
pitch once, get a yes or no, and you're done.

And no, that's NOT a pointy-haired boss problem, those are real
issues, not bureaucrats being stupid.

With the PSP support in mod_python, I'd argue that
the bar has been lowered further.

I'm not familiar with this and will have to check into it further.

But in the short to medium term, expect better application
portability between frameworks - the need to run various popular
applications in different environments is making itself increasingly
evident.

You mean the problems of having a "multitude" of environments are
making themselves evident. If Python is to have anything like PHP's
wide deployment for web apps, the maintainers have to pick one of
those environments (probably Zope, I guess), include it in the
official Python distribution and declare it to be under official
maintenance, and do the same for a database interface. To first
approximation, if something isn't in the official distribution, it
doesn't exist.

Really? At the fundamental level, the DB-API is pretty well
standardised, and there's a collection of well-written modules that
mostly adhere to it.

Nope. Look in the Python distribution, there's nothing like that
there, and similarly in the Python reference manual. Yeah, there's
some random third party modules and docs, but see above, those don't
exist ;-).

 

[David M. Wilson]

The very existence of a "multitude" of Python web environments is a
serious shortcoming of Python as a PHP replacement. PHP comes with
one web environment, not a multitude, so you have just one manual to
read, not a multitude; one codebase to worry about keeping up with the
latest releases for, not a multitude, and so forth.

PHP is largely a very flexible templating system with support for
complex expressions and a huge catalogue of predefined procedures
available in a flat namespace. The manual exists for the above
functionality, and makes the assumption that you invent your 'web
environment' ad hoc.

Indeed the situation with the multitude of Python web CMSes and
frameworks could improve, but I don't think you face half the
difficulty in picking a specific Python one over a specific PHP one.

Again, PHP CMSes tend to advertise their flashy featuresets and latest
'mods', whereas Python CMSes tend to list more practical goals. Take
an example, the Google descriptions for Plone and PostNuke:

Description: The Postnuke Content Management System offers
full CSS support and HTML 4.01 transitional compliance...

Description: Content Management Framework (CMF) that runs on
top of Zope. Can be used as an intranet server, a...


For someone vaguely familiar with Python, and aware of Zope's
excellent reputation, which is the more obvious and affirming choice
of these two?

That's ok, Python has no default support at all, intuitive or
otherwise, for ANY db operations, common or not.

That's precisely the situation Python is in now!

"Obvious", being my favourite word for the month, could maybe have
been put to good use previously. A quick search of Python.org will
bring you up the DB-API docs, which is precisely what happened the
first time I went searching for information about Python and
databases.

The same cannot be said for PHP, where you'll either get a tutorial
for how to use the raw MySQL/Psql/Oracle API functions exported by the
PHP engine, or you'll get faced with a choice between a plethora of DB
'middlewares'.

The site that I worked on spent TWO MILLION U.S. DOLLARS on its web
server hardware.

Was this sometime between 1999-2000?


David.

 

[David M. Cooke]

Nope. Look in the Python distribution, there's nothing like that
there, and similarly in the Python reference manual. Yeah, there's
some random third party modules and docs, but see above, those don't
exist ;-).

http://python.org/peps/pep-0249.html

PEP 249 is the DB-API. Ok, so it's not in the standard distribution --
as you said, there aren't any (SQL) database modules in the standard
distribution [1]. But this is the standard API for database interfacing
(and it's not a third-party API, either). Most third-party modules
conform to it (except for weird or old ones).

[1] maybe gadfly will get added at some point, though.

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.

 

[Paul Rubin]

http://python.org/peps/pep-0249.html

PEP 249 is the DB-API.

That's an informational PEP, which implementations can follow or ignore
as they please.

Ok, so it's not in the standard distribution -- as you said, there
aren't any (SQL) database modules in the standard distribution
[1]. But this is the standard API for database interfacing (and it's
not a third-party API, either). Most third-party modules conform to
it (except for weird or old ones).

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.

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.

Look, I'm not exactly singing the praises of PHP; there's lots of
things they could have done right and didn't, and it's nowhere near as
good a general purpose development language as Python. But it was
written for a specific task that it handles pretty well out of the
box, that Python doesn't handle at all unless you add complex
additional modules maintained by outsiders. Brushing that off and
saying "Spyce, CherryPy, etc. are all out there, just download them"
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".

 

[R. Rajesh Jeba Anbiah]

Excuse me ... Does the life of your children depend on a friendly.
reception of PHP?

Sorry, I couldn't understand what do you mean here (My first
language is Tamil)

I'm just searching a reason for your aggressiveness.

No need to embarrass yourself by researching; I've already said the
reason. Did you read the thread actually?

Never saw that in c.l.py.

Might be some problem with your news server. Perhaps you should
read the thread first

Mit freundlichen Gruessen,

நட்புடன்

HAND.

--
From comp.lang.php
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
If you live in USA, please support John Edwards.
Email: rrjanbiah-at-Y!com

 

[R. Rajesh Jeba Anbiah]

R> If you do *programming* without knowing what to pass to a
R> function or what a function returns, you're a complete idiot as
R> a idiot can be. Moreover, if you take it as an argument

Occasionally, in absence of static typing, you might accidentally call
a function using a return value of another function as an argument and
they are not compatible. W/ python you notice it immediately; with PHP
or Perl your program starts behaving weirdly (if you don't check
return values that is) and you can't pinpoint exactly what went
wrong. This is what makes people run to statically typed languages,
believing that all dynamic typing is shoddy like this.

R> against PHP, you're yet another ignorant and obviously you
R> don't have any rights to speak about PHP nor anything.

I wasn't really talking about PHP, but the approach you took to attack
the arguments of OP (arguments which I agree w/ BTW, but that's
another story).

R> Yes, people with functioning brain may already conculded that
R> when you posted your previous message itself.

Previous message? The one you were replying to was the first I posted
to this thread.

Obviously, you should know what you're doing
(<http://groups.google.com/[email protected]>)
And, please find some time to learn about the error reporting or error
handling mechanism of the languages before throwing your comments.
(Hint: Your comments clearly shows your ignorance in one or more
languages)

HTH. HAND.

--
From comp.lang.php
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
If you live in USA, please support John Edwards.
Email: rrjanbiah-at-Y!com

 

[Paul Boddie]

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?

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

 

[Brandon Blackmoor]

HTH. HAND.

Is this your signature or nickname, or does it perhaps mean something in
your native language (like "ciao", for example)? I assumed it was your
signature, but it doesn't resemble your name, so I thought it may mean
something else. Perhaps it's like those "geek codes" some people put in
their signatures?

bblackmoor
2004-03-07

 

[Geoff Berrow]

Is this your signature or nickname, or does it perhaps mean something in
your native language (like "ciao", for example)?

Hope This Helps. Have A Nice Day