Helpful Information
 
 
Category: Development Articles
Writing CGI Programs in Python

I just finished up developing my first database driven website using PHP/MySQL combination. I know C and SQL and that was all I needed to ace the project. It seems to me that everything that one can do with PERL can be done with PHP. Now comes Python, which I just found out it exists. None of the comparisons include PHP. Why? Am I missing somthing? How different are they? What can one do that the other can not?

Well, PHP is a server-side include language, meant to be embedded directly into HTML. Python is a general purpose programming language like Perl or C. You can do pretty much anything in Python, not just CGI or web stuff.
<br>
<br>
PHP is fine, and it may be all you need. The right tool for the right job, I say. I'm learning PHP myself and my future articles may include a more in-depth comparison.

In one of the examples on Page 6 "Putting it all together," the author uses a series of try:/except: as a DevShed reader noted this can be accomplished easier with the following syntax:
<br>
<br>
if form.has_key('email'):
<br>
     email = form['email'].value
<br>
else:
<br>
     email = ''
<br>
<br>
Or even this:
<br>
<br>
email = ''
<br>
name = ''
<br>
mapping = {
<br>
'email':email,
<br>
'name':name}
<br>
<br>
for m in mapping.keys():
<br>
     if form.has_key(m):
<br>
          mapping[m] = form[m].value
<br>
<br>
Although either one of these options would probably be a better alternative to the syntax used in the article's example, the example does give a correct example on how to use try:/except: properly.

Thank you for this informative and accurate comment.

It's a matter of definitions, but I'm pretty sure that defining PHP as an SSI language is technically and practically wrong.
<br>
<br>
SSI refers to a fairly specific standard, of a highly limited framework for server-side includes, which literally means the ability to include files and program outputs in your files from the server side.
<br>
<br>
PHP, like ePerl and ASP, is *HTML embedded*. In that sense, these languages are suitable for Web development much more than a general purpose non HTML embedded language is.
<br>
<br>
The impression that I think readers get from reading this article is that 'PHP's fine as long as you're doing trivial stuff ('if you need simple SSI pages', and 'PHP may be all you need'). This is simply untrue. Python may be a full featured language with thorough support for many tasks, but so are PHP and Perl (in particular, they both support a wide variety of HTTP, HTML and POP/IMAP functionality).

i agree with zeev that PHP is more than just
<br>
SSI. it allows for embedding logic (loops,
<br>
if stmts, etc.) inside HTML, a
<br>
non-programming language -- this is absolutely a requirement for those whose
<br>
job it is to rapidly prototype full web
<br>
systems that are have CGI execution and
<br>
database access.
<br>
<br>
PHP was created with its own "proprietary"
<br>
language, rather than being based on PERL or
<br>
Python, hence ePERL and Zope, respectively,
<br>
not to mention ASP, *Fusion, etc.
<br>
<br>
as the engineer, it's up to one to decide
<br>
which is the right tool for the job. i
<br>
would like to point out that Python's key
<br>
strength over PERL and PHP is that it is
<br>
easy-to-read, thus making it easy-to-learn,
<br>
and for those following in your footsteps,
<br>
easier-to-maintain.
<br>
<br>
HTH!
<br>
<br>
-wesley

I printed the "printer-friendly" version of your article, and it is buggy: all example text containing HTML tags (e.g. <INPUT>) are suppressed! That makes it rather hard to read...
<br>

We have had a few problems with Netscape 4.6 printing on Linux/Unix machines. One user said he was able to print to PostScript, and then send that file to the printer.
<br>
<br>
DevShed is still unclear on whether on not they can do anything to fix the problem or if this is a bug in Netscape.
<br>
<br>
Please let us know.

Here's the verdict. Netscape will not accurately print pages that contain the IFRAME tag. It will show up fine when you view the page, however if you try to print the page wierd things begin to happen.

Ok, the way I see it (and this is the first time I've actually looked into Python) there's no real advantage over Perl.
<br>
This site has basically described things I could do beforehand using Perl - programming tight code that is revisable should not be up to the programming language, but the programmer. If you aren't able to provide correctly formatted code then maybe you should try your hand in botanics, I hear they're not quite so fussy.
<br>

<br>
People should stop developing new languages and keep on expanding what's there. The philosophy of 'Oh this won't do, I need a new command, let's do everything over' is wasting everybodies time.
<br>

<br>
Thank you for listening.
<br>

<br>
cheers
<br>
Ole

I've tried my hand at both Perl and Python. Here's the _real_ advantage with Python - you can read someone else's Python code. I've come across some Perl code that is REALLY stunning - regexes up the wazoo with no documentation.

The downside to Python is that I find that PyApache isn't anywhere NEAR as fast as Perl. CPAN is also a much more exhaustive code resource than what's available with Python.

So it really boils down to how large is your codebase and are you the only one working on it? On a personal note, I'm 'normally' a C++ guy and I found it difficult to 'think' in Perl.

Uhhh... Python is not exactly 'new', having been around for about a decade.
<br>
<br>
Additionally, perl was made because another language (awk in particular) wouldn't do.
<br>
<br>
I would also add, that there is no real advantage in perl over python. Yes, a programmer _should_ code readable code, but how often is this done? What can you expect from 'Just Another Perl hacker', anyway? ;-)

Thoughtful comments from all, but Ole, I think there were many languages before Perl, COBOL comes to mind.
<br>
<br>
COBOL-REGEXP anyone? No? How about OO-COBOL? Hmmmm? how about Lamda-COBOL for non-side effecting functional composition? Yes? Perhaps ProBOL for unification based rule proofs? Taken to its conclusion, your statements would freeze us in time to be like programming Aimish.
<br>
<br>
This view is as reactionary as the views of people who run to next "new" thing.
<br>
<br>
However, the little I know of Perl makes me feel perhaps it is TOO rich and TOO big. It reminded me of PL/I, a blob of features and syntax, like Perl.
<br>
<br>
Is Python "better"? Is there only "one obvious way to do it"? I don't know. That is the author's claim.
<br>
<br>
So, I may still deal with a little Perl for CGI, but I will take time to learn Python and weigh this matter on my own.
<br>
<br>
FWIW, some very bright C++ers I know were very stern with me in their directive to look into Python before getting to deep into Perl.
<br>
<br>
Cheers!

I have just started to learn Python and I am having problems connecting to a MySQL database. I cant get the example code to work.
<br>
<br>
Here is my newbie code:
<br>
#cat coname.py
<br>
#!/usr/bin/python
<br>
print "Hello, Python!"
<br>
import MySQLdb
<br>
SQLDatabase = "test"
<br>
SQLHost = "localhost"
<br>
SQLUser = "test"
<br>
SQLPassword = "test"
<br>
connectstring = SQLDatabase + "@" + SQLHost + " "
<br>
connectstring = connectstring + SQLUser + " " + SQLPassword
<br>
connection = MySQLdb.mysqldb(connectstring)
<br>
handle = connection.cursor()
<br>
<br>
And here is the error:
<br>
#./coname.py
<br>
Hello, Python!
<br>
Traceback (innermost last):
<br>
File "./coname.py", line 13, in ?
<br>
connection = MySQLdb.mysqldb(connectstring)
<br>
AttributeError: mysqldb
<br>
<br>
I am using MySQLdb-0.1.1, MySQL is 3.22.23b, Python is 1.5.2 on Redhat 5.2 Kernel 2.0.36
<br>
<br>
I have been looking for documentation on the available properties of MySQLdb. (.mysqldb does not seem to be one of them).
<br>
<br>
Thanks in advance for any help.
<br>
<br>

I think it boils down to the fact that there are several good options in the web/db arena and that you should go with the language that has the syntax you're most comfortable with.

Yes, I am having the same problem :(
MySQLdb now is different, and I'm trying to
figure out the new version.

--Daniel

I found a non-brain-dead mySQL Python module; check out http://www.mysql.com/Contrib/MySQLmodule-1.4.tar.gz. It comes with real instructions and really works! :)

Excellent article -- covered a lot of ground in a few pages.
<br>
<br>
When I run the sample1 script in the "Putting the Pieces Together" section, however, I get the following Traceback:
<br>
<br>
<br>
Traceback (innermost last):
<br>
File "/usr/local/apache/cgi-bin/process.py", line 100, in ?
<br>
DisplayForm()
<br>
File "/usr/local/apache/cgi-bin/process.py", line 38, in DisplayForm
<br>
Display(FormInput)
<br>
File "/usr/local/apache/cgi-bin/process.py", line 23, in Display
<br>
SubResult = re.subn('<!-- *** INSERT CONTENT HERE *** -->', Content, TemplateInput)
<br>
File "/var/tmp/python-root/usr/lib/python1.5/re.py", line 52, in subn
<br>
pattern = _cachecompile(pattern)
<br>
File "/var/tmp/python-root/usr/lib/python1.5/re.py", line 33, in _cachecompile
<br>
value = compile(pattern, flags)
<br>
File "/var/tmp/python-root/usr/lib/python1.5/re.py", line 79, in compile
<br>
code=pcre_compile(pattern, flags, groupindex)
<br>
pcre.error: ('nothing to repeat', 6)
<br>
<br>
**********
<br>
<br>
Basically, it looks like re.subn() chokes. Has anyone seen this behavior before? I am running Python 1.5.2 on RH 6.1. I suppose it is possible that that I have a "whitespace" issue -- I had to reformat the code I pulled over from the site. Any help would be appreciated. Thanks in advance.

Try escaping the *'s on line 23 of sample1.py:

SubResult = re.subn("<!-- \*\*\* INSERT CONTENT HERE \*\*\* -->", Content,TemplateInput)

I'm looking at the tutorial in this site, and the give out a little test CGI to help us determine if everything is hooked up, but the stupid tutorial fails to give out the HTML file - COme on you guys, if you take such good effort to write these tutorials, then at least complete the job, and include the HTML that calls the CGI...










privacy (GDPR)