FAQ

Prabahar wrote:

I want to know difference between
Python-cgi and Perl-cgi and also I want
to which one is efficient from the performance.

The difference between a cgi program written in Perl and a cgi program written in Python is the choice of programming language. Both work quite well. You probably want to use whichever programming language you like best, and that can only be discovered from writing programs in both.

In terms of "efficient" (efficiency) , are you talking about how much memory the program uses, how fast the program executes, or how much time it takes to write and debug the program? There are differences between the two in these regards, but I do not have any reliable information that quantifies those differences, and the differences are likely to vary greatly depending on the nature and length of the program, and how efficiently written the code is.

I think, generally, if you really like programming in Perl, there is probably no reason not to use it (at least for typical/short cgi programs) - it has been the default choice for years; conversely, if you really like programming in Python, you will probably be happy to tackle any challenges associated with using it for cgi.


Notes:
Perl cgi execution is generally offered by all hosts that offer cgi; Python cgi execution is offered by fewer hosts (but some of those hosts are really great).

With either language, if execution "performance" is a concern, you may want to use something along the lines of mod_python or mod_perl which embed a persistent interpreter in your web server. This lets you avoid the overhead of starting an external interpreter and avoids the penalty of Perl/Python start-up time, giving faster time to execution.

Was this at all the information you were looking for? Why do I think you may have intended a very technical question? If so, you may have to be a little more specific about the sort of differences you are interested in understanding.


Eric




From http Sat Jul 30 08:40:08 2005
From: http (Paul Rubin)
Date: 29 Jul 2005 23:40:08 -0700
Subject: A replacement for lambda
References: <867jf9jmfw.fsf@bhuda.mired.org>
<TqAGe.14234$G71.2883@bignews3.bellsouth.net>
<42ead151@nntp0.pdx.net>
<slrndem1hk.q3g.rootrot@jimrthy.is-a-geek.com>
Message-ID: <7x64usokzb.fsf@ruckus.brouhaha.com>

James Richards <rootrot at govtabuse.com> writes:
Personally, I can't recall any decent programmer I know who objects
to actually writing out a variable name. In fact, I don't know a
single "real" programmer (this is one who writes programs he intends
to look at again in, say, 3 weeks) who doesn't insist on writing
"real" variable names.
The issue is whether you want to name every intermediate result in
every expression.

sum = a + b + c + d + e

is a lot nicer than

x1 = a + b
x2 = c + d
x3 = x1 + e
sum = x2 + x3

the language has nicely kept all those intermediate results anonymous.

Python has first-class functions, which, like recursion, is a powerful
idea that takes some getting used to. They let you say things like

def derivative(f, t, h=.00001): # evaluate f'(t) numerically
return (f(t+h) - f(t)) / h

dy_dt = derivative(cos, 0.3) # approx. -sin(0.3)

With anonymous functions, you can also say:

dy_dt = derivative(lambda x: sin(x)+cos(x), 0.3) # approx. cos(.3)-sin(.3)

Most Python users have experience with recursion before they start
using Python, so they don't see a need for extra keywords to express
it. Those not used to first-class functions (and maybe some others)
seem to prefer extra baggage. For many of those used to writing in
the above style, though, there's nothing confusing about using a
lambda there instead of spewing extra verbiage to store that
(lambda x: sin(x)+cos(x)) function in a named variable before
passing it to another function.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 9 | next ›
Discussion Overview
grouppython-list @
categoriespython
postedJul 29, '05 at 12:21p
activeJul 30, '05 at 7:05a
posts9
users7
websitepython.org

People

Translate

site design / logo © 2019 Grokbase