Python vs. Perl

[Michael McGarry]

Hi,

I am just starting to use Python. Does Python have all the regular
expression features of Perl?

Is Python missing any features available in Perl?

Thanks,

Michael

[Roy Smith]

Michael McGarry <re**********@n ospam.org> wrote:

I am just starting to use Python. Does Python have all the regular
expression features of Perl?
I can't vouch for "all", but the Python reference manual for the "re"
module (http://docs.python.org/lib/module-re.html) says, "This module
provides regular expression matching operations similar to those found
in Perl".
Is Python missing any features available in Perl?

Are you talking specifically about regex, or about the language in
general? If the latter, then the answer is "Yes, and this is a Good
Thing". If you meant the former, then I suspect the answer is that
anything you can do with a Perl regex you can also do with a Python
regex. I'm a pretty heavy regex user, and I've never found anything I
wanted to do which I was unable to.

The biggest difference between regex support in Perl and Python is that
Perl has regex syntax built into the core language, while Python does it
with a module that you have to import and then call functions inside
that module. Which you like better is a matter of personal opinion.
Like most Perl-Python feature comparisons, the Perl version usually ends
up more compact, but the Python version ends up easier to understand.

[Christopher De Vries]

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy. It seems to me that
any program you can write in python could also be written in perl. What
it comes down to for me was which language most fit the way I tend to
think. I decided python was that language, and I found everything very
intuitive. I have a good friend who thinks in perl and is very
productive using it.

Other people might disagree, but when I was looking at perl and python
I borrowed recent copies of "Learning Perl" and "Learning Python" from
the O'Reilly series and after reading each, decided I preferred python.
You can find out about most of the features in those books.

Chris

[loritsch]

Christopher De Vries wrote:

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy.

To help aid in this discussion, the following Python and Perl
philosophy links might be useful:
http://c2.com/cgi/wiki?PythonPhilosophy
http://www.maths.adelaide.edu.au/~cm...ntro/x175.html

Now, so that I don't start another Python vs. Perl flamewar, I'd like
to inform everyone that I'm about to make a few generalizations based
on my experience. As should be understood implicitly, one man's
experience is not the experience of everyone...

As a user of both languages, I've found that what Perl and Python
programmers have in common is that they were looking for a better tool
when they stumbled across their language of choice... After all, one
can be productive in both languages.

What I've also noticed that people who use Perl tended to start using
it as a way to make either C or shell scripting tasks easier (after
all, this is Perl's original intended audience). Many of these
developers have gone on to use Perl for bigger and better things, but
without a lot of discipline (use strict, and a lot of work with the
Exporter), Perl doesn't scale very well to large projects. My belief
is that Perl's strength (TMTOWTDI) is also it's greatest weakness.

I've also noticed that Python programmers tend to be a more diverse
lot. While Guido originally intended Python to be a second language
for C/C++ developers, it is also quite useful as a first language.
Python's philosophy is more that there should a clear understandable
way to do things, and that readability counts. That is not to say you
can't perform tasks in multiple ways, it is just to say that Python
doesn't believe in TMTOWTDI as Perl does.

So the bottom line is this. In choosing Perl or Python, the real
difference should be your mindset, and what you intend to use it for.
If you want a multiparadigm programming language that offers wonderful
OO support, is easy to learn, and in which you will naturally write
maintainable code, choose Python.

On the other hand, if you are looking for a language to text-processing
and to perform short quick shell scripting like tasks, choose Perl.
While both languages can be used to perform both sets of tasks, my
belief is that one should pair a language and a task by strengths
rather than what can be done in each language.
I hope this helps!

Michael Loritsch

[Michael McGarry]

lo******@gmail. com wrote:

Christopher De Vries wrote:

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy.

To help aid in this discussion, the following Python and Perl
philosophy links might be useful:
http://c2.com/cgi/wiki?PythonPhilosophy
http://www.maths.adelaide.edu.au/~cm...ntro/x175.html

Now, so that I don't start another Python vs. Perl flamewar, I'd like
to inform everyone that I'm about to make a few generalizations based
on my experience. As should be understood implicitly, one man's
experience is not the experience of everyone...

As a user of both languages, I've found that what Perl and Python
programmers have in common is that they were looking for a better tool
when they stumbled across their language of choice... After all, one
can be productive in both languages.

What I've also noticed that people who use Perl tended to start using
it as a way to make either C or shell scripting tasks easier (after
all, this is Perl's original intended audience). Many of these
developers have gone on to use Perl for bigger and better things, but
without a lot of discipline (use strict, and a lot of work with the
Exporter), Perl doesn't scale very well to large projects. My belief
is that Perl's strength (TMTOWTDI) is also it's greatest weakness.

I've also noticed that Python programmers tend to be a more diverse
lot. While Guido originally intended Python to be a second language
for C/C++ developers, it is also quite useful as a first language.
Python's philosophy is more that there should a clear understandable
way to do things, and that readability counts. That is not to say you
can't perform tasks in multiple ways, it is just to say that Python
doesn't believe in TMTOWTDI as Perl does.

So the bottom line is this. In choosing Perl or Python, the real
difference should be your mindset, and what you intend to use it for.
If you want a multiparadigm programming language that offers wonderful
OO support, is easy to learn, and in which you will naturally write
maintainable code, choose Python.

On the other hand, if you are looking for a language to text-processing
and to perform short quick shell scripting like tasks, choose Perl.
While both languages can be used to perform both sets of tasks, my
belief is that one should pair a language and a task by strengths
rather than what can be done in each language.
I hope this helps!

Michael Loritsch

Thank you all for your input. Please feel free to keep this discussion
going.

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

I welcome any opinions on this.

[Christos TZOTZIOY Georgiou]

On Sat, 11 Dec 2004 15:10:04 -0700, rumours say that Michael McGarry
<re**********@n ospam.org> might have written:

Thank you all for your input. Please feel free to keep this discussion
going.

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

I welcome any opinions on this.

I don't know if my opinion will help, but I know if you follow my
advice, it will be enlightening :)

Both languages cover all of your requirements. So read as much
documentation needed to write some simple programs as examples doing
similar tasks to the one you want in *both* languages. Test them that
they work. Then forget about your problems. Go to an island. Dream.
Relax. Come back without explanations six months later, and if they
take you back in the same company, read *both* of your example programs.
You'll know then which language to select (I would select the language
of the island natives, but that's another story :)
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...

[Timo Virkkala]

Christos TZOTZIOY Georgiou wrote:

Both languages cover all of your requirements. So read as much
documentation needed to write some simple programs as examples doing
similar tasks to the one you want in *both* languages. Test them that
they work. Then forget about your problems. Go to an island. Dream.
Relax. Come back without explanations six months later, and if they
take you back in the same company, read *both* of your example programs.
You'll know then which language to select (I would select the language
of the island natives, but that's another story :)

That's unfair! That approach leads to Python every time!

Oh wait, that was the purpose.. :)

--
Timo Virkkala

[Jon Perez]

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

For GUI development and front end, Python most likely has better
facilities than Perl, but still leaves a lot to be desired (after
getting a taste of Delphi 3rd party VCL components, all other RAD
environments pale in comparison).

[Ian Bicking]

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than Perl?
I'm not sure; generally I'd guess better, as it avoids the shell with
all the shell's issues, and provides a more controlled programmatic way
of interacting with subprocesses. OTOH, Perl might have perfectly good
modules for doing the same thing. I can only say it's been missing for
a while in Python, and it's good to see this done right.

--
Ian Bicking / ia**@colorstudy .com / http://blog.ianbicking.org

[Keith Dart]

Ian Bicking wrote:

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front
end code for my simulations in C. I want a language that can support
SQL, Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than Perl?
I'm not sure; generally I'd guess better, as it avoids the shell with
all the shell's issues, and provides a more controlled programmatic way
of interacting with subprocesses. OTOH, Perl might have perfectly good
modules for doing the same thing. I can only say it's been missing for
a while in Python, and it's good to see this done right.

Yow, I must not get picked up in Google enough. ;-) The "proctools"
module in the pyNMS package <http://sourceforge.net/projects/pynms/> has
been around for years. I use it all the time for shell-like stuff. There
is also an "expect" module, and the "termtools" module. If you need a
more complete process spawning and controlling framework then use pyNMS.
It can "juggle" multiple processes, reaps child status (no
zombies), operates asynchronously (The ProcManager object is a SIGCHLD
handler), and works with pty's and pipes. It also offers a "thread-like"
interface for Python subprocesses (uses fork). Can leave some fd's open
that you specify, can run the subprocess as a different user, and more...
Check it out.

--
\/ \/
(O O)
-- --------------------oOOo~(_)~oOOo----------------------------------------
Keith Dart <kd***@kdart.co m>
public key: ID: F3D288E4
=============== =============== =============== =============== =============== =