How's ruby compare to it older brother python

[Hunn E. Balsiche]

in term of its OO features, syntax consistencies, ease of use, and their
development progress. I have not use python but heard about it quite often;
and ruby, is it mature enough to be use for developing serious application,
e.g web application as it has not many features in it yet.

I've given up on Perl for its ugly syntax and it is not the easiest language
to learn. How about PHP?

Thanks

[Michael]

in term of its OO features, syntax consistencies, ease of use, and their
development progress. I have not use python but heard about it quite often;
and ruby, is it mature enough to be use for developing serious application,
e.g web application as it has not many features in it yet.

I've given up on Perl for its ugly syntax and it is not the easiest language
to learn. How about PHP?

IMO Ruby is closer to Perl than Python as far as clearness of it's
syntax. I really like Python better. PHP isn't as garbled as Perl but it
isn't as flexible either and it's still not nearly as clean as Python.
Of the four languages (Perl, Python, PHP, and Ruby) I find Python the
easiest to work in. I use Python for command-line programming, web
programming (mod_python), and GUI programming (wxPython and Pygame) and
find it a good general purpose language.

[Peter Maas]

Hunn E. Balsiche wrote:

I've given up on Perl for its ugly syntax and it is not the easiest language
to learn. How about PHP?

http://www.python.org/doc/Comparisons.html

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplusr.de
-------------------------------------------------------------------

[Peter Maas]

Hunn E. Balsiche wrote:

I've given up on Perl for its ugly syntax and it is not the easiest language
to learn. How about PHP?

I forgot http://dada.perl.it/shootout, which is great for performance
comparisons. Source code of the tests can be viewed easily to get a
feeling for the strengths and weaknesses of the syntax as well.

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplusr.de
-------------------------------------------------------------------

[Leif B. Kristensen]

Hunn E. Balsiche wrote:

in term of its OO features, syntax consistencies, ease of use, and
their development progress. I have not use python but heard about it
quite often; and ruby, is it mature enough to be use for developing
serious application, e.g web application as it has not many features
in it yet.

I've given up on Perl for its ugly syntax and it is not the easiest
language to learn. How about PHP?

It really depends on what you'll want to do. PHP is a great language for
getting dynamic HTML pages up and running quickly. Perl is great for
its string-handling abilities. (On my Web pages, I actually call a Perl
script from PHP precisely for this reason.)

However, both PHP and Perl can be very unwieldy for large projects. I'm
a newcomer to Python, but it seems to scale much better than the other
P-languages.

For a first tour of Python, I'll suggest that you read the excellent
tutorial by the language's author, Guido van Rossum:

http://www.python.org/doc/current/tut/

regards,
--
Leif Biberg Kristensen
http://solumslekt.org/
Validare necesse est

[John Roth]

"Hunn E. Balsiche" <hu******@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...

in term of its OO features, syntax consistencies, ease of use, and their
development progress. I have not use python but heard about it quite often; and ruby, is it mature enough to be use for developing serious application, e.g web application as it has not many features in it yet.
As another poster has mentioned, Ruby is more closely related
to Perl than to Python. While I don't use it, people I respect who
have moved to Ruby say it has a couple of real killer features;
in particular the way blocks and the pervasive use of the visitor
pattern come together change the way one writes programs for
the better.

As far as syntax is concerned, there doesn't seem to be a
huge amount of difference. Syntax is syntax, and every language
has it's little pecularities.

I haven't seen enough of it to make me want to learn it, but it's
on my list of languages to play with sometime.

John Roth
Thanks

[Bruno Desthuilliers]

Hunn E. Balsiche wrote:

in term of its OO features, syntax consistencies, ease of use, and their
development progress. I have not use python but heard about it quite often;
and ruby, is it mature enough to be use for developing serious application,
e.g web application as it has not many features in it yet.
Syntax : both Ruby and Python are pretty clean, Ruby being IMHO more
consistent and Python easier to grasp

OO : Ruby is OO all the way, and pretty close to Smalltalk. Python is
more a mix of procedural and OO with some functional stuff too.

Web : Python may have a bit more existing solutions, and a real killer
app (Zope). Now, AFAIK, Ruby has also some interesting stuff for web
developpement.

IMHO, both are really great languages. I really like the elegance of
Ruby and the ease of use of Python. So try both and pick the one that
fits you're brain !-)
I've given up on Perl for its ugly syntax and it is not the easiest language
to learn.
No comment...
How about PHP?

<troll>
One of the dumbest 'scripting' language I've ever worked with, but still
a good solution for web developpement when you have no better (read :
Python or Ruby) choice.
</troll>

Bruno

[Cameron Laird]

In article <iL***************@news4.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:

[Leif B. Kristensen]

Cameron Laird rose and spake:

In article <iL***************@news4.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:
.

getting dynamic HTML pages up and running quickly. Perl is great for
its string-handling abilities. (On my Web pages, I actually call a
Perl script from PHP precisely for this reason.)

.
I hear this more often than I understand it. Perl certainly
does support many string-oriented operations. What's a speci-
fic example, though, of an action you feel more comfortable
coding in external Perl? I suspect there's something I need
to learn about PHP's deficiencies, or Perl's power.

I'm glad that you asked :-)

The routine is for a phonetic search in Norwegian 18th century names,
which can be spelled in an amazing number of different ways. As I found
that the Soundex algorithm was useless for Norwegian spellings, I
invented my own. It's not really an algorithm, but a series of
substitutions that reduces names to a kind of primitives. Thus, eg.
Berthe, Birthe, Bergitte, Bergit, Birgit, Børte, Berit, and Brit, which
actually are interchangeable spellings of the same name, are reduced to
BRT.

Here's a small sample:

$str =~ s/HN/N/g; # John --> JON
$str =~ s/TH/T/g; # Thor --> TOR
$str =~ s/CHI/KJ/g; # Torchild --> TORKJL
$str =~ s/CHE/KJ/g; # Michel --> MKJL
$str =~ s/KKE/KJ/g; # Mikkel --> MKJL
$str =~ s/KIEL/KJL/g; # Kield -> Kjeld ( --> KJL)
$str =~ s/CH/K/g; # Christen -> Kristen ( --> KRSTN)
$str =~ s/CA/KA/g; # Carl -> Karl ( --> KAL)
$str =~ s/RL/L/g; # Thorleif <=> Tollef <=> Tolf ( --> TOLF)

I use a Perl script to transform my genealogy data from a FoxPro
database to MySQL command scripts. Thanks to the excellent module
DBD::XBase by Jan Pazdziora, this is a quite simple task.

In theory, the web routine for phonetic searches might have been
implemented in PHP. The trouble with that is that I would have to
maintain both a PHP and a Perl version of the same routine. I find it
much easier to just copy and paste the whole mess (at present about 120
lines) between the encoding and the decoding routines in Perl, and run
an exec("perl norphon.pl $name") from PHP.

regards,
--
Leif Biberg Kristensen
http://solumslekt.org/
Validare necesse est

[Cameron Laird]

In article <kn***************@news2.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:

[Roy Smith]

In article <10*************@corp.supernews.com>,
cl****@lairds.com (Cameron Laird) wrote:

In article <kn***************@news2.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:
.
.
.

which can be spelled in an amazing number of different ways. As I found
that the Soundex algorithm was useless for Norwegian spellings, I
invented my own. It's not really an algorithm, but a series of
substitutions that reduces names to a kind of primitives. Thus, eg.

.
.
.
"Canonicalization" is one name in academic English for this transformation.

But is it the cannonical name?

[Phil Tomson]

In article <10*************@news.supernews.com>,
John Roth <ne********@jhrothjr.com> wrote:

"Hunn E. Balsiche" <hu******@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...

in term of its OO features, syntax consistencies, ease of use, and their
development progress. I have not use python but heard about it quite

often;

and ruby, is it mature enough to be use for developing serious

application,

e.g web application as it has not many features in it yet.

As another poster has mentioned, Ruby is more closely related
to Perl than to Python. While I don't use it, people I respect who
have moved to Ruby say it has a couple of real killer features;
in particular the way blocks and the pervasive use of the visitor
pattern come together change the way one writes programs for
the better.

As far as syntax is concerned, there doesn't seem to be a
huge amount of difference. Syntax is syntax, and every language
has it's little pecularities.

Well, there is one big difference syntactically: Python uses indentation
as syntax and Ruby doesn't. Personally I don't prefer Python's
'indentation-as-syntax' since it means that syntactically significant
pieces of my code are invisible and if the tab settings in my editor are
not the same as yours it can make it difficult to share code (or even
worse, it might look like everything is OK when we share code, but the
code which looks exactly the same to each of us, might not be depending
on how tabs are or are not expanded). It would also seem to be a pain for
cutting & pasting code as well.
However, some people really like Python's indentation-as-syntax, so YMMV.

Your best bet is to actually use each language for a small project
so that you spend about a day with each language. You'll find that while
on the surface both languages seem quite similar, at a deeper level they
each have a very different effect on how you think about and approach the
problem. Some people find that Ruby best fits with their brain and others find
Python a better fit. You won't know until you try.

Phil

[Cameron Laird]

In article <kn***************@news2.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:

[Cameron Laird]

In article <c6*******@enews4.newsguy.com>,
Phil Tomson <pt***@aracnet.com> wrote:

[John Roth]

"Phil Tomson" <pt***@aracnet.com> wrote in message
news:c6*******@enews4.newsguy.com...

In article <10*************@news.supernews.com>,
John Roth <ne********@jhrothjr.com> wrote:

"Hunn E. Balsiche" <hu******@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...

in term of its OO features, syntax consistencies, ease of use, and their development progress. I have not use python but heard about it quiteoften;

and ruby, is it mature enough to be use for developing serious

application,

e.g web application as it has not many features in it yet.

As another poster has mentioned, Ruby is more closely related
to Perl than to Python. While I don't use it, people I respect who
have moved to Ruby say it has a couple of real killer features;
in particular the way blocks and the pervasive use of the visitor
pattern come together change the way one writes programs for
the better.

As far as syntax is concerned, there doesn't seem to be a
huge amount of difference. Syntax is syntax, and every language
has it's little pecularities.

Well, there is one big difference syntactically: Python uses indentation
as syntax and Ruby doesn't. Personally I don't prefer Python's
'indentation-as-syntax' since it means that syntactically significant
pieces of my code are invisible and if the tab settings in my editor are
not the same as yours it can make it difficult to share code (or even
worse, it might look like everything is OK when we share code, but the
code which looks exactly the same to each of us, might not be depending
on how tabs are or are not expanded). It would also seem to be a pain for
cutting & pasting code as well.

As I said in another post, indentation is the reason I learned
Python in the first place, but it's not the reason I stay with
the language. In fact, I've come to the very heretical view
that the indentation sensitivity is a language design mistake.
It should be the editor's job to handle that level of detail in
a manner that the developer finds workable.

One reason I think it's a language design mistake is that
it's not recursive. That is, it's not possible to shift from
expression level indentation back to statement level
indentation without major disruptions. This is needed for
embedded blocks.

I think Ruby has a reasonable middle ground here: its use of
'end' is fairly unobtrusive compared to, for example, C, C++,
C# or Java. Even so, I think that a reasonable programming
editor would get them out of my face while I was programming.

The tab issue is one of those relatively inconsequential things
that people seem to love to argue about: I'd rather be able to
tell the editor how I want the program formatted, and have done
with it.
Phil

[Leif B. Kristensen]

Cameron Laird rose and spake:

Long ago, I was myself involved in a tiny way with
parish records for Finnmark and Troms. I wish I'd
been able to do more ...
That's very interesting from my point of view. Starting this autumn, by
the way, the Norwegian National Archive will begin to publish scanned
images of parish records on the Web. They plan to finish this job in a
couple of years, and then go on to other popular sources for
genealogists, such as probates, court records, and land transactions.
I'm glad things are working for you. I'm all for
not-duplicating effort. Do you realize you can use
PHP from the command line? As I understand your
explanation, it doesn't reflect AT ALL on a defici-
ency in PHP string-handling; to my eye, PHP can do
the operation just about as well as Perl.
It probably could, but at the time I wrote my FoxPro extraction script I
was very much into Perl. I was very happy to find the XBase module, and
besides, I have been unable to find something similar in any other
language that I have more than a nodding aquaintance with.
I continue to conclude that all these languages are
roughtly equally competent at managing strings.

Perhaps, but right now I think that I'm in love with Python. Consider
these two equivalent routines in PHP and Python:

PHP:
function get_place($x) {
$query = "select pl1, pl2, pl3, pl4, pl5
from places where place_id = $x";
$handle = mysql_query($query);
$row = mysql_fetch_row($handle);
$pl_string = '';
if ($p_num == 1) return '';
$i = 0;
for ($j = 0; $j<5; $j++) {
if ($row[$j] != '' && substr($row[$j], 0, 1) != '-') {
$pl[$i] = $row[$j];
$i++;
}
}
for ($j = 0; $j < ($i-1); $j++)
$pl_string .= $pl[$j].', ';
$pl_string .= $pl[$i-1];
return ltrim(rtrim($pl_string));
}

Python:
def get_place(x):
c=db.cursor()
c.execute("select pl1, pl2, pl3, pl4, pl5
from place where place_id = %d" % (x))
result=c.fetchone()
return ', '.join([p for p in result if p and p[0] != '-'])

Consider that my entire Web site is written in PHP. I stumbled across
Python just a few weeks ago, and got substantial help with the latter
version of the routine from Paul Rubin on this list.

My PHP coding may be suboptimal, but in terms both of codability and
readability as well as in sheer elegance, I find the Python version
superior in any way.

regards,
--
Leif Biberg Kristensen
http://solumslekt.org/
Validare necesse est

[Cameron Laird]

In article <gx***************@news4.e.nsc.no>,
Leif B. Kristensen <ju******@solumslekt.org> wrote:

Cameron Laird rose and spake:

[Brandon J. Van Every]

Cameron Laird wrote:

.
It's not just that "You won't know until you try" ("is it better
to have children, or join the monastery?"); it's that you won't
know until you try, *and it's inexpensive to try*! It's eminently
feasible to gain experience in either language with a few hours (!)
of work, as opposed to the weeks that must precede enlightenment
about, say, J2EE servers.

Of course, those of us who are more into the Complete Waste Of Time [TM]
theory of selecting software components will simply give you the bottom
line:

- If you like Perl, you'll like Ruby. If you think Perl is a bletcherous
hack, you'll like Python.
- The Python community dwarfs the Ruby community.
- Both languages are slow.
- Python has lotsa libraries but not everything. Ask here regarding your
specific needs. Even if Python were the most elegant language in the world,
that's not useful if you must write everything from scratch and don't have
time to do it.

This is the kind of information you get by simply asking people and reading
lotsa archives. Some people say "Try it yourself!" is the only way to
learn. They are wrong, and they often don't value people's time. You
really can rely on other people's reported experiences of the nuclear
mushroom cloud exploding over the horizon. It is not strictly necessary to
walk into Ground Zero yourself.

Now, if you're going to argue "it's just a little Ruby code..." why don't
you try multiplying that by all the languages in the comp.lang.* hierarchy
that you could potentially be selecting from? Take a spin by the Language
Shootouts if you want to spin your head some more.
http://www.bagley.org/~doug/shootout/
http://dada.perl.it/shootout/
You need a filter of some kind for cutting down the options. I suggest
asking people, and seeing what languages actually got used for jobs relevant
to your software problem / industry.

I'm waiting for someone to say that my participation in this thread
constitutes trolling. I find it amusing that the boundary between
"intelligent language discussion" and "trolling" is mainly a matter of who
likes who, not the content. And, this is all I have to say on the subject,
so have fun.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."

[Florian Gross]

Hunn E. Balsiche wrote:

[Ruby, Python]
I've given up on Perl for its ugly syntax and it is not the easiest language
to learn. How about PHP?

All these suck. You guys should grow up and start programming in *real*
programming languages like Befunge.

Oh, and you forgot to cross post to all the other 54 comp.lang groups.

And now: Can we please never have threads like this one ever again?
We're getting them on a twice-per-month base right now which makes these
topics get old and very uninteresting quickly.

PS: Don't take this too personal, but all this wouldn't have happened if
you had searched in other resources before posting here.

Regards,
Florian Gross

[Steve Lamb]

On 2004-04-26, Phil Tomson <pt***@aracnet.com> wrote:

Well, there is one big difference syntactically: Python uses indentation
as syntax and Ruby doesn't. Personally I don't prefer Python's
'indentation-as-syntax' since it means that syntactically significant
pieces of my code are invisible and if the tab settings in my editor are
not the same as yours it can make it difficult to share code (or even

Why is this trotted out every time? I guarentee that my code will look
perfectly fine in your editor. I cannot guarentee the reverse as while you
might have a penchant for tabs I do not. I am not alone in that regard.
Here's a snippet from the Python style guide:

Tabs or Spaces?
Never mix tabs and spaces. The most popular way of indenting Python is with
spaces only. The second-most popular way is with tabs only. Code indented with
a mixture of tabs and spaces should be converted to using spaces exclusively.
(In Emacs, select the whole buffer and hit ESC-x untabify.) When invoking the
python command line interpreter with the -t option, it issues warnings about
code that illegally mixes tabs and spaces. When using -tt these warnings
become errors. These options are highly recommended!

So unless your tab setting is 0 syntactically significant pieces of code
should always have a different indention level. Furthermore if the
program(mers) follow the style guide then that is a non-issue.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Phil Tomson]

In article <c6************@ID-207230.news.uni-berlin.de>,
Brandon J. Van Every <tr***************************@yahoo.com> wrote:

Cameron Laird wrote:

.
It's not just that "You won't know until you try" ("is it better
to have children, or join the monastery?"); it's that you won't
know until you try, *and it's inexpensive to try*! It's eminently
feasible to gain experience in either language with a few hours (!)
of work, as opposed to the weeks that must precede enlightenment
about, say, J2EE servers.

Of course, those of us who are more into the Complete Waste Of Time [TM]
theory of selecting software components will simply give you the bottom
line:

- If you like Perl, you'll like Ruby. If you think Perl is a bletcherous
hack, you'll like Python.
- The Python community dwarfs the Ruby community.
- Both languages are slow.
- Python has lotsa libraries but not everything. Ask here regarding your
specific needs. Even if Python were the most elegant language in the world,
that's not useful if you must write everything from scratch and don't have
time to do it.

This is the kind of information you get by simply asking people and reading
lotsa archives. Some people say "Try it yourself!" is the only way to
learn. They are wrong, and they often don't value people's time. You
really can rely on other people's reported experiences of the nuclear
mushroom cloud exploding over the horizon. It is not strictly necessary to
walk into Ground Zero yourself.

Now, if you're going to argue "it's just a little Ruby code..." why don't
you try multiplying that by all the languages in the comp.lang.* hierarchy
that you could potentially be selecting from? Take a spin by the Language
Shootouts if you want to spin your head some more.
http://www.bagley.org/~doug/shootout/
http://dada.perl.it/shootout/
You need a filter of some kind for cutting down the options. I suggest
asking people, and seeing what languages actually got used for jobs relevant
to your software problem / industry.

It seems as though he has already done this. He was interested in Ruby
and Python (N=2). From there a couple of people (including myself)
suggested that he make the determination about which to study indepth by
actually doing a bit of coding in both languages. Spending a day or two
on this exercise doesn't seem excessive if you're serious about selecting
your 'next language' to learn in depth.

Phil

[Ruby Tuesdays]

Would this super perl program of yours can convert the massive amount of
perl script to ruby or python?

If it could, it would be great so ruby/python programmers does not have to
learn those cryptic perl-ish syntax and the non-OOish scripting language.

[Paramjit Oberoi]

>>>getting dynamic HTML pages up and running quickly. Perl is great for

its string-handling abilities. (On my Web pages, I actually call a
Perl script from PHP precisely for this reason.)

I have always felt that just like Jason Orendorff's path.py module makes
working with paths so incredibly convenient, a similarly well-designed
regex.py might make text processing as easy in python as it is in perl.

Unfortunately I don't deal enough with regexes to have the motivation to
actually put this idea into practice. Maybe someone who does can take a
shot at it?

-param

[Brandon J. Van Every]

Phil Tomson wrote:

In article <c6************@ID-207230.news.uni-berlin.de>,
Brandon J. Van Every wrote:

You need a filter of some kind for cutting down the options. I
suggest asking people, and seeing what languages actually got used
for jobs relevant to your software problem / industry.

It seems as though he has already done this.

He may very well have... I'm late to the thread. Consider it embedded
advice for anyone *other* than him who may be reading, now or in the future.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Trollhunter" - (n.) A person who habitually accuses
people of being Trolls.

[Kirk Strauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 2004-04-26T20:50:22Z, Paramjit Oberoi <p_********@hotmail.com> writes:

I have always felt that just like Jason Orendorff's path.py module makes
working with paths so incredibly convenient, a similarly well-designed
regex.py might make text processing as easy in python as it is in perl.

I haven't noticed much of a different between Perl's regex and Python's
re.py module, other than I'm now typing:

pattern.match(string)

instead of

string ~= pattern

- --
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAjYbp5sRg+Y0CpvERAge8AJ4s6qDPoCVB6BFrBjFOYf hPMTkFoACfcfdZ
6d2x9KAJGe+T67W6W4Y1zVI=
=j8qP
-----END PGP SIGNATURE-----

[Erik Max Francis]

"Brandon J. Van Every" wrote:

- Python has lotsa libraries but not everything. Ask here regarding
your specific needs. Even if Python were the most elegant language in
the world, that's not useful if you must write everything from scratch
and don't have time to do it.
Pay close attention to this passage; it's relevant below.
This is the kind of information you get by simply asking people and
reading
lotsa archives. Some people say "Try it yourself!" is the only way to
learn. They are wrong, and they often don't value people's time.
"Try it yourself" is certainly not the only way to learn, but it should
be a more than sufficient one for a self-proclaimed accomplished
programmer. Certainly it better values other people's time in order to
do the research you can do on your own and then come to them with any
additional -- far more intelligent -- questions you might have, rather
than punting on them and expecting them to do all your research for you.
Take a spin by the Language
Shootouts if you want to spin your head some more.
http://www.bagley.org/~doug/shootout/
http://dada.perl.it/shootout/
You need a filter of some kind for cutting down the options.
Above you say that what's most highly valued is development time
("that's not useful if you must write everything from scratch and don't
have time to do it"). So why are you referencing a shootout page that
characterizes only the speed at which programs execute, without any
information about how hard each program was to write? You're telling
someone to value their own development time, and then pointing them to
something totally irrelevant to that point.
I'm waiting for someone to say that my participation in this thread
constitutes trolling.

Zzzzzzzz.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Money talks / But love is for real / And you know that
-- Neneh Cherry

[Michael]

In theory, the web routine for phonetic searches might have been
implemented in PHP. The trouble with that is that I would have to
maintain both a PHP and a Perl version of the same routine. I find it
much easier to just copy and paste the whole mess (at present about 120
lines) between the encoding and the decoding routines in Perl, and run
an exec("perl norphon.pl $name") from PHP.

I've wondered if there is really a reason why a single language
processor couldn't be made that Perl, Python, PHP, etc could all be
compiled into. Not necesarily a byte code system like Java but just a
shared language processing core. Then the various languages could
directly work with libraries written in the other languages. How much
does the syntax actually effect the abilities of the language? How much
should it effect the abilities of the language?

[gabriele renzi]

il Mon, 26 Apr 2004 19:52:28 -0700, Michael
<mo*****@mlug.missouri.edu> ha scritto::

I've wondered if there is really a reason why a single language
processor couldn't be made that Perl, Python, PHP, etc could all be
compiled into.

that is the parrot, the perl6 VM I believe :)

[Ville Vainio]

>>>>> "Leif" == Leif B Kristensen <ju******@solumslekt.org> writes:

Leif> Here's a small sample:

Leif> $str =~ s/HN/N/g; # John --> JON
Leif> $str =~ s/TH/T/g; # Thor --> TOR
Leif> $str =~ s/CHI/KJ/g; # Torchild --> TORKJL

....

Isn't that trivial in all languages that support regexps?

All too often Perl gets too much credit for doing things that are
every bit as easy/easier in other languages.

As a bonus, this python snippet returns the changes done for every
individual regex pair:
-------------
import re

repls = [
('NH','N'),
('TH','T'),
('CHI','KJ'),
('hel.*o','ll') # one regex just for show

]

def subst_many(pairs, s):
res = []
for pat,repl in pairs:
s, n = re.subn(pat, repl, s)
res.append(n)
return s,res

result, changes_done = subst_many(repls, my_text_file)


--
Ville Vainio http://tinyurl.com/2prnb

[Asun Friere]

Kirk Strauser <ki**@strauser.com> wrote in message news:<87************@strauser.com>...

I haven't noticed much of a different between Perl's regex and Python's
re.py module, other than I'm now typing:

pattern.match(string)

instead of

string ~= pattern

How does pattern (in the python example) come to have a 'match'
method?

Wouldn't you need to import the re module and compile the pattern
first? (And wouldn't you use 'search' rather than 'match'?) And
other steps, depending on what you want to do with the resulting match
object.

Regex is much more 'immediate' in Perl. Probably the only time I
would reach for Perl rather than for python is when I knew a task
involved a lot of regex (and no object orientation).

[Ville Vainio]

>>>>> "Asun" == Asun Friere <af*****@yahoo.co.uk> writes:

Asun> Wouldn't you need to import the re module and compile the
Asun> pattern first? (And wouldn't you use 'search' rather than
Asun> 'match'?) And

I rarely compile regexps, just pass the string to the re functions.

Asun> Regex is much more 'immediate' in Perl. Probably the only

I mostly use re.findall and re.sub, which are every bit as immediate
as the perl counterparts. Match objects provide flexibility - if you
want immediacy, just define a utility function that removes the
flexibility and provides the convenience.

Asun> time I would reach for Perl rather than for python is when I
Asun> knew a task involved a lot of regex (and no object
Asun> orientation).

If the task involves a lot of anything it can often be factored out to
some functions, and Python wins again. Perl5 is one of those languages
with no reason to exist anymore.

--
Ville Vainio http://tinyurl.com/2prnb

[Roy Smith]

Ville Vainio <vi***@spammers.com> wrote:

>> "Asun" == Asun Friere <af*****@yahoo.co.uk> writes:

Asun> Wouldn't you need to import the re module and compile the
Asun> pattern first? (And wouldn't you use 'search' rather than
Asun> 'match'?) And

I rarely compile regexps, just pass the string to the re functions.

For the occasional ad-hoc match, this is fine. The advantage of
pre-compiling is that it's faster, since it doesn't have to recompile
the regex each time.

I don't see anything in the reference manual which says re.match()
caches compilations, but I suspect it does. Even a trivial check for
"thisRegEx is lastRegEx" would be sufficient to negate the speed
advantage of pre-compiling in most cases. Anybody know if it does this?

[Peter Hansen]

Roy Smith wrote:

I don't see anything in the reference manual which says re.match()
caches compilations, but I suspect it does. Even a trivial check for
"thisRegEx is lastRegEx" would be sufficient to negate the speed
advantage of pre-compiling in most cases. Anybody know if it does this?

Found after trying a half dozen different searches. (Short answer: yes.)

http://groups.google.com/groups?q=co...t%40python.org

-Peter

[Skip Montanaro]

Asun> Regex is much more 'immediate' in Perl.

Sure, it's syntactically bound into the language. There will always be an
extra constant overhead to enable regular expressions in Python. That
doesn't make them any less powerful than the Perl variety. It's simply a
pair of different design decisions Guido and Larry made (along with a few
others).

Asun> Probably the only time I would reach for Perl rather than for
Asun> python is when I knew a task involved a lot of regex (and no
Asun> object orientation).

Why? I write non-object-oriented Python code all the time. To make the
Python/Perl switch you'd still have to shift your mental gears to deal with
a different syntax, different way of getting at and using functionality that
isn't builtin, etc. Even with lots of regex fiddling to do, I think the
extra overhead of using regexes in Python would be swamped by the other
differences. In addition, as Jamie Zawinski suggests, regular expressions
are not always the best choice.

Skip

[Roy Smith]

Skip Montanaro <sk**@pobox.com> wrote:

In addition, as Jamie Zawinski suggests, regular expressions
are not always the best choice.

Regular expressions are like duct tape. They may not be the best tool
for everything, but they usually get the job done.

[Skip Montanaro]

Roy> For the occasional ad-hoc match, this is fine. The advantage of
Roy> pre-compiling is that it's faster, since it doesn't have to
Roy> recompile the regex each time.

Roy> I don't see anything in the reference manual which says re.match()
Roy> caches compilations, but I suspect it does.

Yup, every call does. I believe the only time you really need to compile
them is if you have more than 100 different regular expressions. In this
case the caching code clears the cache when the threshold is reached instead
of just picking a random few elements to toss (which seems like a mistake to
me but one that should rarely be encountered). Look in sre.py at _compile()
and _MAXCACHE.

Skip

[Cameron Laird]

In article <ma*************************************@python.or g>,
Skip Montanaro <sk**@pobox.com> wrote:

[Cameron Laird]

In article <ro***********************@reader2.panix.com>,
Roy Smith <ro*@panix.com> wrote:

Skip Montanaro <sk**@pobox.com> wrote:

In addition, as Jamie Zawinski suggests, regular expressions
are not always the best choice.

Regular expressions are like duct tape. They may not be the best tool
for everything, but they usually get the job done.

And leave a sticky discolored mess behind.
--

Cameron Laird <cl****@phaseit.net>
Business: http://www.Phaseit.net

[Peter Hansen]

Cameron Laird wrote:

In article <ma*************************************@python.or g>,
Skip Montanaro <sk**@pobox.com> wrote:

differences. In addition, as Jamie Zawinski suggests, regular expressions
are not always the best choice.

"suggests"? I thought he was "chanting", or "intoning", or
"inveighing" or "denouncing" or ... Well, I'll say it on my
own behalf: friends, REs are not always the best choice <URL:
http://www.unixreview.com/documents/...1037388368795/ >.

"Denouncing" it definitely was. I wanted to find the original
source for myself, and Google conveniently provided it. Still
fun reading, and quite relevant to the thread:

http://slashdot.org/comments.pl?sid=19607&cid=1871619

-Peter

[Peter Hansen]

Skip Montanaro wrote:

Roy> I don't see anything in the reference manual which says re.match()
Roy> caches compilations, but I suspect it does.

Yup, every call does. I believe the only time you really need to compile
them is if you have more than 100 different regular expressions. In this
case the caching code clears the cache when the threshold is reached instead
of just picking a random few elements to toss (which seems like a mistake to
me but one that should rarely be encountered).

I would think the mistake would be in writing code that actually
depended on more than 100 different regular expressions, without
explicitly compiling the expressions itself. The 100-expression
cache seems like a cheap, transparent optimization that shouldn't
cause anyone trouble in well-written code.

-Peter

[Wilk]

Roy Smith <ro*@panix.com> writes:

Ville Vainio <vi***@spammers.com> wrote:

>>>>> "Asun" == Asun Friere <af*****@yahoo.co.uk> writes:

Asun> Wouldn't you need to import the re module and compile the
Asun> pattern first? (And wouldn't you use 'search' rather than
Asun> 'match'?) And

I rarely compile regexps, just pass the string to the re functions.

For the occasional ad-hoc match, this is fine. The advantage of
pre-compiling is that it's faster, since it doesn't have to recompile
the regex each time.

I don't see anything in the reference manual which says re.match()
caches compilations, but I suspect it does. Even a trivial check for
"thisRegEx is lastRegEx" would be sufficient to negate the speed
advantage of pre-compiling in most cases. Anybody know if it does this?

Looking at the source code of sre.py, it seems that regexp are
auto-cached anyway...

def match(pattern, string, flags=0):
"""Try to apply the pattern at the start of the string, returning
a match object, or None if no match was found."""
return _compile(pattern, flags).match(string)

def compile(pattern, flags=0):
"Compile a regular expression pattern, returning a pattern object."
return _compile(pattern, flags)

def _compile(*key):
# internal: compile pattern
p = _cache.get(key)
if p is not None:
return p

I think the advantage of re.compile is just to don't have to repeat the
string everytimes...

--
Wilk - http://flibuste.net

[Paramjit Oberoi]

> Asun> Regex is much more 'immediate' in Perl.

Sure, it's syntactically bound into the language. There will always be an
extra constant overhead to enable regular expressions in Python. That

If only compiled regular expression objects allowed easy access to the
last match object, python regxes would become significantly more
convenient. For example, today you have to write:

m = myregex.match(line)
if (m):
xyz = m.group('xyz')

It would be much easier to do:

if myregex.match(line):
xyz = myregex.lastm.group('xyz')

Having to introduce a new variable name for a match object just
muddles the code unnecessarily in common regex usage scenarios.

-param

[Peter Hansen]

Paramjit Oberoi wrote:

Asun> Regex is much more 'immediate' in Perl.

Sure, it's syntactically bound into the language. There will always be an
extra constant overhead to enable regular expressions in Python. That

If only compiled regular expression objects allowed easy access to the
last match object, python regxes would become significantly more
convenient. For example, today you have to write:

m = myregex.match(line)
if (m):
xyz = m.group('xyz')

It would be much easier to do:

if myregex.match(line):
xyz = myregex.lastm.group('xyz')

Having to introduce a new variable name for a match object just
muddles the code unnecessarily in common regex usage scenarios.

Wouldn't that be a fairly trivial class to write, and use
in your own code? This is the kind of thing people tend
to whip up on the fly and add to their little bag of tools
if they really like it.

Something like (untested, not real code, just for the idea):

class myregex(re):
def match(self, data):
self.lastm = self.pattern.match(data)
return self.lastm

-Peter

[Roy Smith]

In article <pa****************************@hotmail.com>,
Paramjit Oberoi <p_********@hotmail.com> wrote:

Asun> Regex is much more 'immediate' in Perl.

Sure, it's syntactically bound into the language. There will always be an
extra constant overhead to enable regular expressions in Python. That

If only compiled regular expression objects allowed easy access to the
last match object, python regxes would become significantly more
convenient. For example, today you have to write:

m = myregex.match(line)
if (m):
xyz = m.group('xyz')

It would be much easier to do:

if myregex.match(line):
xyz = myregex.lastm.group('xyz')

Having to introduce a new variable name for a match object just
muddles the code unnecessarily in common regex usage scenarios.

-param

I like that idea. I would go one step further and eliminate the lastm
attribute, so you could just do:

if myregex.match(line):
xyz = myregex.group('xyz')

Maybe even go all the way and let a regex object have all the methods of
a match object, cache a reference to the last match, and delegate calls
to the match object methods to the cached match object.

[Roy Smith]

In article <no********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:

Wouldn't that be a fairly trivial class to write, and use
in your own code?

It would be. And everybody would invent their own flavor. Putting it
into the core means everybody does it the same way, so everybody's code
is easier to understand and maintain.

[Michele Dondi]

ùOn Mon, 26 Apr 2004 16:55:02 -0400, "Ruby Tuesdays"
<No**********************@yahoo.com> wrote:

Would this super perl program of yours can convert the massive amount of
perl script to ruby or python?

If it could, it would be great so ruby/python programmers does not have to
learn those cryptic perl-ish syntax and the non-OOish scripting language.

Huh?!?
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__

[Tad McClellan]

Michele Dondi <bi******@tiscalinet.it> wrote:

ùOn Mon, 26 Apr 2004 16:55:02 -0400, "Ruby Tuesdays"
<No**********************@yahoo.com> wrote:

Would this super perl program of yours can convert the massive amount of
perl script to ruby or python?

If it could, it would be great so ruby/python programmers does not have to
learn those cryptic perl-ish syntax and the non-OOish scripting language.

Huh?!?

Simply make a killfile entry and move on.
--
Tad McClellan SGML consulting
ta***@augustmail.com Perl programming
Fort Worth, Texas

[Carl Banks]

Paramjit Oberoi wrote:

Asun> Regex is much more 'immediate' in Perl.

Sure, it's syntactically bound into the language. There will always be an
extra constant overhead to enable regular expressions in Python. That

If only compiled regular expression objects allowed easy access to the
last match object, python regxes would become significantly more
convenient. For example, today you have to write:

m = myregex.match(line)
if (m):
xyz = m.group('xyz')

It would be much easier to do:

if myregex.match(line):
xyz = myregex.lastm.group('xyz')

Having to introduce a new variable name for a match object just
muddles the code unnecessarily in common regex usage scenarios.

Hmm. The reason this hasn't been done is that it makes the match
method non-reentrant. For example, suppose you call some functions in
between the matching and use of the matched object, like this:

if myregex.match(line):
xyz = (subprocess(line[myregex.lastm.end():])
+ myregex.lastm.group(1))

And suppose subprocess goes on to use the same regexp. By the time
subprocess returns, myregex.lastm could have been overwritten. This
is not a far-fetched example at all; one could easily encounter this
problem when writing, say, a recursive descent parser.

Murphy's law says that if anything bad can happen, sooner or later it
will, and this is why non-reentrant functions like your proposed
myregex.match are so heinous. So, I can't agree that this is a good
idea as it stands.

--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon

[Roy Smith]

Carl Banks <im*****@aerojockey.invalid> wrote:

Hmm. The reason this hasn't been done is that it makes the match
method non-reentrant. For example, suppose you call some functions in
between the matching and use of the matched object, like this:

if myregex.match(line):
xyz = (subprocess(line[myregex.lastm.end():])
+ myregex.lastm.group(1))

And suppose subprocess goes on to use the same regexp. By the time
subprocess returns, myregex.lastm could have been overwritten. This
is not a far-fetched example at all; one could easily encounter this
problem when writing, say, a recursive descent parser.

I don't see that this is any worse than any other stateful object. If
you change the state of the object, you can't expect to get the same
data from it as you did before.

[Carl Banks]

Roy Smith wrote:

Carl Banks <im*****@aerojockey.invalid> wrote:

Hmm. The reason this hasn't been done is that it makes the match
method non-reentrant. For example, suppose you call some functions in
between the matching and use of the matched object, like this:

if myregex.match(line):
xyz = (subprocess(line[myregex.lastm.end():])
+ myregex.lastm.group(1))

And suppose subprocess goes on to use the same regexp. By the time
subprocess returns, myregex.lastm could have been overwritten. This
is not a far-fetched example at all; one could easily encounter this
problem when writing, say, a recursive descent parser.

I don't see that this is any worse than any other stateful object.

It's worse because, unlike most objects, regexp objects are usually
global (at least they are when I use them). Moreover, the library
encourages us to make regexp objects global by exposing the regexp
compiler. So even if you personally use local regexps (and accept the
resulting performance hit), many will declare them global.

In other words, myregexp.match is essentially a global function, so
it shouldn't have state.
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon