> Is anyone capable of providing Python advantages over PHP if there are > any?
Much more compact and yet much more readable code, making it easier to maintain and extend your programs. -- Leif Biberg Kristensen http://solumslekt.org/
Good - but it hardly mentions the issue of security - which seems like a bit of a problem for PHP at the moment. -- __________ |im |yler http://timtyler.org/ t...@tt1lock.org Remove lock to reply.
>Good - but it hardly mentions the issue of security - which seems >like a bit of a problem for PHP at the moment.
I don't think so. Bad programmers are able to write bad programs in any language. Maybe there are more bad php programmers than python programmers and the 70% of the dynamic world wide web is copied from user comments in the php.net/manual. However one of the worst cases is the sql injection attack. And sql injections must be handled neither by php nor by python but by the programmer.
I think a website or even a large portal is a well constructed database with triggers and stored procedures and some "echo", "if", "foreach" and "while" in the php code.
To me the advantage of python seems to come out when you deal with xml, file handling or when you have to write a native server application for your website. But I am so new here, others may say other things.
I've been a PHP and Perl programmer (amongst others) for 10 years or more now, and a Python coder for 3 or so.
I have come to hate PHP now, it's pseudo-OOP is awful, it's dog slow at handling XML, it's so easy to use that most of the programmers I've had contact with are very sloppy and do things like extract($_GET); or put database usernames and passwords in index.php. I also have to agree that php.net/manual seems to be the main reference that coders use - which is not good if the comments are wrong!
Python seems to force you to write better code, maybe because of the indentation, exception handling, proper OOP etc. Plus it's not so tied into web stuff, in fact most of my Python programming is for the desktop.
I still love Perl, it's a bit of an art form, as "there's more than one way to do it", whereas Python usually only allows one way to do it, which may or may not be a better mantra....
I've come to allocate PHP the same standing as ASP, VB or Java - the language is OK, but the programmers are usually crap.
"Mage" wrote: > I don't think so. Bad programmers are able to write bad programs in any > language.
in PHP, good programmers are able to write bad programs without even noticing.
(every successful server attack I've seen closely the last few years have been through PHP. it's totally without competition in this area)
> However one of the worst cases is the sql injection attack. And sql > injections must be handled neither by php nor by python but by the > programmer.
sql injection? what's your excuse for not using data binding?
>sql injection? what's your excuse for not using data binding?
I am not sure I truly understand your question. So far my own servers didn't get successful sql injection attack. I just saw some on other sites and did one for demonstration.
Avoid them is easy with set_type($value,"integer") for integer values and correct escaping for strings.
However, php programmers usually don't initialize their variables because they don't have to do. They even turn off warnings and errors. Our php errorlog at my full time working company is so huge I could cry. We have php-copypasters. I don't know anyone IRL who uses python. So I started to learn it.
On Sat, 23 Apr 2005 20:13:24 +0200, Mage wrote: > Avoid them is easy with set_type($value,"integer") for integer values and > correct escaping for strings.
"Avoiding buffer overflows in C is easy, as long as you check the buffers each time."
The *existence* of a technique to avoid problems is not in question. The problem is when the language makes it easier to *not* do the checks than to do the checks. Any look at the real world shows that that pattern causes trouble, and that clearly, the mere *existence* of a way to not get in trouble is not sufficient in the general case.
Despite the fact that all you have to do to avoid cutting your finger off with a saw is not stick your finger in the saw, most people, even carpentry professionals, are going to want to use finger-guards and other safety equipment. A programmer turning down such security protection (without another good reason, which does happen), is being like the guy too macho to use the finger guard; stupidity induced by arrogance, not some one no longer using training wheels. Using PHP and futzing with SQL directly is probably not a good enough reason, as surely PHP has safer libraries available. (If not, my opinion of PHP goes down another notch.)
Data binding with something like SQLObject makes it *easier* to be secure than insecure; barring an out-and-out bug in SQLObject (given the nature of the requisite bug, it is extremely unlikely to have survived this long), a programmer must go *way* out of their way to introduce the SQL injection attacks that so plague PHP projects.
> >Is anyone capable of providing Python advantages over PHP if there are > >any?
> I am also new to python but I use php for 4 years. I can tell:
> - python is more *pythonic* than php > - python has its own perfume > http://www.1976.com.tw/image/trussardi_python_uomo.jpg and it's nice. > php doesn't have any smell > - writing python programs you feel much better
Mage wrote: > However one of the worst cases is the sql injection attack. And sql > injections must be handled neither by php nor by python but by the > programmer.
But Python's DB-API (the standard way to connect to an SQL database from Python) makes escaping SQL strings automatic. You can do this:
cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
And "foo'bar" will be implicitly escaped to whatever is appropriate for your database. How's that for Python handling SQL injection automatically?
Leif K-Brooks wrote: > Mage wrote: >> However one of the worst cases is the sql injection attack. And sql >> injections must be handled neither by php nor by python but by the >> programmer.
> But Python's DB-API (the standard way to connect to an SQL database > from Python) makes escaping SQL strings automatic. You can do this:
> cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
> And "foo'bar" will be implicitly escaped to whatever is appropriate > for your database. How's that for Python handling SQL injection > automatically?
Not. Perl and Java use similar methods where one can specify place holders, and pass on the data unescaped. But still injection is possible. Moreover, a programmer still has to check if the values are acceptable or not.
AFAIK PHP is not able to do this, but goes at great length to "protect" newbie programmers at great length, and hence give them a false feeling of security. Defensive programming or a defensive programming language is wrong.
"Simon John" <simoninusa2...@yahoo.co.uk> writes: > I still love Perl, it's a bit of an art form, as "there's more than one > way to do it", whereas Python usually only allows one way to do it, > which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2) faster improvements in the language.
To be a Perl expert, you have to know which of the many ways to do various things is the fasted under what conditions. Python programmers seldom have to worry about that - there's usually only one [obvious] way to do things, so you just do it that way.
Having only one obvious way to do things means developers only have to worry about impact on that way when making improvements, which will speed them up.
The problem these days is that there are now multiple ways to do a variety of things, because we have the "new, pythonic" way and the "old, backwards-compatible way". So it's no longer clear which is the fastest - and in the case of generators versus list comprehensions, it's not clear which you should be using. To bad.
<mike -- Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: > "Simon John" <simoninusa2...@yahoo.co.uk> writes:
>> I still love Perl, it's a bit of an art form, as "there's more than >> one way to do it", whereas Python usually only allows one way to do >> it, which may or may not be a better mantra....
> The Python mantra leads to 1) less programmer overhead, and 2) faster > improvements in the language.
> To be a Perl expert, you have to know which of the many ways to do > various things is the fasted under what conditions.
Why?
> Python programmers > seldom have to worry about that - there's usually only one [obvious] > way to do things, so you just do it that way.
I doubt that :-D. I have never seen a programming language that forced me in such a way :-D.
> Having only one obvious way
I doubt that too ;-)
> to do things means developers only have to > worry about impact on that way when making improvements, which will > speed them up.
Yeah, Perl programmers are extremely slow ;-)
> The problem these days is that there are now multiple ways to do a > variety of things, because we have the "new, pythonic" way and the > "old, backwards-compatible way". So it's no longer clear which is the > fastest -
In most cases, why worry? If speed is an issue you should probably have picked a different programming language in the first place (for that part of the code).
> and in the case of generators versus list comprehensions, > it's not clear which you should be using. To bad.
Use the one that is the easiest to read and understand by yourself. That's how I program Perl, and that's how I am going to program Python.
An overloaded toolbox doesn't mean that if you have to hang a painting on the wall that you have to think for 6 hours which tool you should use. You just take the one that does the job in a way you feel comfortable with. I know that the Perl mantra is often misunderstood, but in my experience only by people who have very little experience with the language.
John Bokma wrote: > Not. Perl and Java use similar methods where one can specify place holders, > and pass on the data unescaped. But still injection is possible.
Leif K-Brooks wrote: > John Bokma wrote: >> Not. Perl and Java use similar methods where one can specify place >> holders, and pass on the data unescaped. But still injection is >> possible.
> How?
my $sort = $cgi->param( "sort" ); my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
John Bokma wrote: > my $sort = $cgi->param( "sort" ); > my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
And the equivalent Python code:
cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort, [some_id])
You're right, of course, about being *able* to write code with SQL injection vulnerabilities in Python. But it's not even close to being as easy as in PHP.
> But Python's DB-API (the standard way to connect to an SQL database > from Python) makes escaping SQL strings automatic. You can do this:
> cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
So. I've been writing SQL queries in Python like this, using PostgreSQL and psycopg:
cursor.execute("select * from foo where bar=%s" % baz)
Is that wrong, and how should I have been supposed to know that this is bad syntax? No doc I have seen actually has told me so. -- Leif Biberg Kristensen http://solumslekt.org/
>> my $sort = $cgi->param( "sort" ); >> my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
> And the equivalent Python code:
> cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort, > [some_id])
> You're right, of course, about being *able* to write code with SQL > injection vulnerabilities in Python. But it's not even close to being as > easy as in PHP.
I'm bewildered why you haven't mentioned magic quotes. A one line change to the configuration file can render your PHP site almost entirely immune to SQL injection attacks.
>>> I still love Perl, it's a bit of an art form, as "there's more than >>> one way to do it", whereas Python usually only allows one way to do >>> it, which may or may not be a better mantra....
>> The Python mantra leads to 1) less programmer overhead, and 2) faster >> improvements in the language.
>> To be a Perl expert, you have to know which of the many ways to do >> various things is the fasted under what conditions.
> Why?
One of the stated conditions for more than one Perl position I've looked at.
>> Python programmers >> seldom have to worry about that - there's usually only one [obvious] >> way to do things, so you just do it that way.
> I doubt that :-D. I have never seen a programming language that forced > me in such a way :-D.
I'd say you haven't seen a lot of languages - including Python. COBOL, Eiffel, Rexx, Scheme, APL and a few others come to mind as "there's usually only one way to do things". Python is one of them.
As a programmer, I find this very *freeing*. I can quite worrying about implementation minutia - just do things the obvious way - and worry instead about the "big picture"
>> Having only one obvious way > I doubt that too ;-)
Try programming in older Python for a while. You'll quit doubting it.
>> to do things means developers only have to >> worry about impact on that way when making improvements, which will >> speed them up. > Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things than the Python developers.
>> The problem these days is that there are now multiple ways to do a >> variety of things, because we have the "new, pythonic" way and the >> "old, backwards-compatible way". So it's no longer clear which is the >> fastest - > In most cases, why worry? If speed is an issue you should probably have > picked a different programming language in the first place (for that > part of the code).
You apparently haven't been programming in Python very long. If speed is an issue, you should probably pick a different algorithm. Well-written Python programs use the C-coded parts of Python for the time-critical part of the code.
>> and in the case of generators versus list comprehensions, >> it's not clear which you should be using. To bad. > Use the one that is the easiest to read and understand by yourself. > That's how I program Perl, and that's how I am going to program Python.
The thing is, in Python there usually is one obvious way to do things. That's changed in recent years as improvements have been added without dropping the features they replaced so as not to break old programs.
> An overloaded toolbox doesn't mean that if you have to hang a painting > on the wall that you have to think for 6 hours which tool you should > use. You just take the one that does the job in a way you feel > comfortable with. I know that the Perl mantra is often misunderstood, > but in my experience only by people who have very little experience with > the language.
The problem with using "the way you feel comfortable with" is that it may not be comfortable for the maintainer - even if that's you six months from now. My Perl evolved from very shell script like (lots of backticks and passing around the full text of files) to one more C-like as I used the language. That change was largely driven by performance concerns as my understanding of the language grew.
<mike -- Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
