Though I would love to use Perl in automation and other scripting tasks, I become a faint-hearted (I admit it) when I have to write Perl CGI for handling Form Data. I am happy, if I can use PHP in order to handle Form Data. Where does Python fit with respect to doing things such as RegEx, Pattern Matching, etc. which Perl does just fine and in a superb way and handling form data and handing them over from one web page to another without having us get tired of writing codes (PHP seems better here)?

Thanks in advance for your views!

P.S.: One of my Senior Managers has suggested me to go for Python as I am already having good exposures to Perl.

pan64

02-22-2013 01:45 AM

regex and pattern matching are more or less on the same level, just the syntax differs.
both have a lot of libraries, and a huge amount of info available on the web. So probably python is better (in general), but you need to learn both of them to be able to use them professionally.

onebuck

02-22-2013 10:00 AM

Moderator Response

Moved: This thread is more suitable in <Programming> and has been moved accordingly to help your thread/question get the exposure it deserves.

Python has only lexical scoping. What it does not have is dynamic scoping, which Perl has by the use of local, but I don't think that's an argument either way – dynamic scoping is “evil”.

Some more differences:
- Python has nicer object model than Perl.
Some syntax differences which I notice the most:
- I've grown to love how I can omit parenthesis in Perl in many cases.
- I hate indention dictating blocks in Python.
- I find $, @ and % too much of a hassle to type.

dugan

02-22-2013 11:43 AM

Quote:

Originally Posted by devUnix
(Post 4897251)

I have to write Perl CGI for handling Form Data. I am happy, if I can use PHP in order to handle Form Data. Where does Python fit with respect to doing things such as RegEx, Pattern Matching, etc. which Perl does just fine and in a superb way and handling form data and handing them over from one web page to another without having us get tired of writing codes (PHP seems better here)?

There's not even a question. Python with a web framework like Django or Flask. Like PHP, but superior in every way.

Python started supporting closures only from Python 3, which, AFAIK, is not as popular as Python 2.

Not true, Python 2 does support closures, just in a limited way, which was solved by introducing nonlocal statement in Python 3 and which I guess you're talking about. But here's an example of closure that works in Python 2:

Code:

def pow(x):
def fn(y):
return y ** x
return fn

pow2 = pow(2)
pow3 = pow(3)

print pow2(10)
print pow3(10)

To OP: while Perl supports regular expressions as part of the language, in Python they're provided as functions by re module from standard library. AFAIK, Perl's regexps have better Unicode support, can't tell you anything more specific about it as I know very little Perl. Regarding web apps, if I were you, I wouldn't bother with CGI at all and use some small web framework instead. For Python I like Flask, for Perl there's Mojolicious and Dancer.

Sergei Steshenko

02-22-2013 05:23 PM

Quote:

Originally Posted by mina86
(Post 4897611)

Python has only lexical scoping. What it does not have is dynamic scoping, which Perl has by the use of local, but I don't think that's an argument either way – dynamic scoping is “evil”.

Some more differences:
- Python has nicer object model than Perl.
Some syntax differences which I notice the most:
- I've grown to love how I can omit parenthesis in Perl in many cases.
- I hate indention dictating blocks in Python.
- I find $, @ and % too much of a hassle to type.

- once stumbled upon a program adding some kind of parenthesis to Python code top facilitate code refactoring. If you think about it, code without clearly visible block boundaries is very fragile in case of refactoring.

Quote:

I find $, @ and % too much of a hassle to type

- and I find supporting somebody else's code with no indication what a name means too much of a a hassle to support. Furthermore, because of lack of '$', '@' Python formatted output sucks - rewrite in Python

Code:

my $n = 10;
my $f = 1.23;
my $s = "a string";

print "integer: $n; float: $f; string: $s\n";

audriusk

02-23-2013 06:16 AM

That's block scoping, which Python doesn't have, but it doesn't mean that Python's scoping is not lexical. Here's a code snippet in Python (lexical scoping):

Code:

x = 1

def foo():
global x
print x
x = 2

def bar():
x = 3
foo()

bar() # Prints 1
print x # Prints 2

And here's identical snippet in bash (dynamic scoping):

Code:

x=1

foo() {
echo $x
x=2
}

bar() {
local x=3
foo
}

bar # Prints 3
echo $x # Prints 1

Quote:

Originally Posted by Sergei Steshenko
(Post 4897810)

- and I find supporting somebody else's code with no indication what a name means too much of a a hassle to support. Furthermore, because of lack of '$', '@' Python formatted output sucks - rewrite in Python

OK, I guess it comes down to personal preference, because I don't mind Python's way of interpolating strings.

I did read the link you gave, it was quite interesting and useful read, thanks for that. Actually, I took bash example in my previous post from Dynamic Scoping part and rewrote it in Python. If you're trying to tell that Python's scoping is not lexical, I disagree. My given Python and bash examples clearly behave differently, even though they're mostly identical. Also the fact that Python does have closures ("lexical closures" in full, which by definition capture their lexical scope) should take away any doubts. Your Perl example demonstrates that code blocks create their own scope, in Python only functions do that. In fact, the Wikipedia article does mention this (emphasis mine):

Quote:

Many languages take function scope slightly further, allowing variables to be made local to just part of a function; rather than having the entire function as its scope, a variable might have block scope, meaning that it's scoped to just a single block of statements.

<...> languages with block scope typically also allow the use of "naked" blocks, which frequently serve no other purpose than to allow fine-grained control of variable scope.

Sergei Steshenko

02-23-2013 07:34 AM

Quote:

Originally Posted by audriusk
(Post 4898104)

OK, I guess it comes down to personal preference, because I don't mind Python's way of interpolating strings.

I did read the link you gave, it was quite interesting and useful read, thanks for that. Actually, I took bash example in my previous post from Dynamic Scoping part and rewrote it in Python. If you're trying to tell that Python's scoping is not lexical, I disagree. My given Python and bash examples clearly behave differently, even though they're mostly identical. Also the fact that Python does have closures ("lexical closures" in full, which by definition capture their lexical scope) should take away any doubts. Your Perl example demonstrates that code blocks create their own scope, in Python only functions do that. In fact, the Wikipedia article does mention this (emphasis mine):

AFAIR, in practice (in year 2000) Python had just two levels of scope - top level and inside a function.

audriusk

02-23-2013 08:06 AM

Quote:

Originally Posted by Sergei Steshenko
(Post 4898118)

AFAIR, in practice (in year 2000) Python had just two levels of scope - top level and inside a function.

I vaguely remembered something from then (I got introduced to Python around that time), so googled up and found this:

Quote:

In Python 2.1, statically nested scopes were added as an optional feature, to be enabled by a from __future__ import nested_scopes directive. In 2.2 nested scopes no longer need to be specially enabled, and are now always present.

So you're right: up till version 2.1 there was no nested scoping in Python.

dugan

02-23-2013 11:12 AM

Quote:

Originally Posted by Sergei Steshenko
(Post 4898085)

Sucks means that you need to split the string and use all those % format specifiers.

You don't. The last line of post #9 is how it's done these days.

Sergei Steshenko

02-23-2013 07:25 PM

Quote:

Originally Posted by dugan
(Post 4898211)

You don't. The last line of post #9 is how it's done these days.

If you mean this:

Code:

print 'integer: {}; float: {:.2f}; string: {}'.format(n, f, s)

line, it still sucks, but for different reasons.

1) usage of '{...}' - which are items not present in the rest of the code. I mean in Perl for, say, scalar variable I use '$' - be it in '$x = 1;' or in '" ... $x ...";
2) usage of .format(n, f, s).

On the latter. In Perl I write simply as I think:

Code:

print "integer: $n; float: $f; string: $s\n";

.

I mean that the variables appear in the output string in the places they are supposed to be expanded. Nothing is specified in addition.

In case of Python:

Code:

print 'integer: {}; float: {:.2f}; string: {}'.format(n, f, s)

I have two headaches:

a) I need to specify formats in the string;
b) I need to specify variables in 'format(n, f, s)' in correct order - this is inherited from "C" *printf functions. I.e. it sucks in "C" too.

Overall, monitoring Python evolution is funny. Originally it was conceived as under-Perl, i.e. some Perl features were intentionally dropped. And now Python 3 catches up with Perl introducing features Perl already head in 1994.