How's ruby compare to it older brother python

[Wallclimber]

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.

I have to agree with the original poster. My *only* complaint about
Python are not regex search, but regex search and replace operations.
Perl : s =~ s/(\w+)\s*=\s*(\d+)/$2 <= $1/g;
Python : regex.sub(s, "(\w+)\s*=\s*)\d+)", (lambda m: m.group(2)+" <=
"+m.group(1)))

I didn't try this out so there might be some syntax problems in there,
but you get the idea. Is there a 'nicer' way to do this in python?
Using 'group' and lambda functions is really quite messy. (An,
obviously, in real life usage, the replacemant function can be much
bigger...)

I'd be most grateful if somebody could show me a cleaner way to do
this.

Thanks,
Tom Verbeure

 

[Carl Banks]

I have to agree with the original poster. My *only* complaint about
Python are not regex search, but regex search and replace operations.
Perl : s =~ s/(\w+)\s*=\s*(\d+)/$2 <= $1/g;
Python : regex.sub(s, "(\w+)\s*=\s*)\d+)", (lambda m: m.group(2)+" <=
"+m.group(1)))

I didn't try this out so there might be some syntax problems in there,
but you get the idea. Is there a 'nicer' way to do this in python?
Using 'group' and lambda functions is really quite messy. (An,
obviously, in real life usage, the replacemant function can be much
bigger...)

I'd be most grateful if somebody could show me a cleaner way to do
this.

Define the following helper function (mrd stands for match replace
dict, I wanted something small, call it what you want):

def mrd(m):
d = {}
for i,g in enumerate(m.groups()):
d[str(i+1)] = g
return d


Then your regex becomes:

regex.sub(s, "(\w+)\s*=\s*)\d+)", "%(2)s <= %(1)s" % mrd(m))


Were you aware that, when a dict appears on the right side of string
interpolation operator %, you can reference values in the dict by
name? That's what the above trick does. Not quite down to Perl
minimalism, but clean.

 

[Leif B. Kristensen]

S Koppelman wrote:

[Leif B. Kristensen]

Well, that's not PHP's fault, especially with such straightforward
regexps. The only reason to user perl over PHP in that case is the
valid one you cite: you already wrote the damned code in perl.

I actually did rewrite the routine once in PHP, but I usually find
regexps in any other language than Perl a PITA.

Meanwhile, wouldn't it run more efficiently if you hosted your perl
functions under mod_perl or some other persistent harness like a SOAP
or XML-RPC daemon and had the PHP call accross to that?

I don't run my own Web server, so I have limited opportunities for
configuration. Exec() seems to be the only viable alternative for now.

Execing out
and having perl launch, compile and run your script each time is a
waste of resources, not to mention needlessly slow. You might not
notice it if you're the only person using it, but if there's a sudden
uptick in traffic to your site from fellow Scandinavian diaspora
genaologists, you will.

I had expected some penalty for running a Perl routine from PHP, but in
practice, the process is blazingly fast. You may verify this for
yourself if you visit http://solumslekt.org/slekta/innhold.php and
enter some common Norwegian name like "Berte" in the "Fornavn" (given)
field, and "Olsdatter" in the "Etternavn" (surname, or more likely a
patronym) field. The page is generated and served in a fraction of a
second, as you can see in the blue box at the bottom.

I wonder if Apache is smart enough to keep the compiled Perl code cached
in memory, even if mod_perl is not loaded?

regards,

 

[Peter Otten]

I have to agree with the original poster. My *only* complaint about
Python are not regex search, but regex search and replace operations.
Perl : s =~ s/(\w+)\s*=\s*(\d+)/$2 <= $1/g;
Python : regex.sub(s, "(\w+)\s*=\s*)\d+)", (lambda m: m.group(2)+" <=
"+m.group(1)))

I didn't try this out so there might be some syntax problems in there,
but you get the idea. Is there a 'nicer' way to do this in python?

Your example suggests that the Python equivalent for $1 is \1:
'1 <= a 3 <= b c = d'

Peter

 

[Duncan Booth]

(e-mail address removed) (Wallclimber) wrote in

I have to agree with the original poster. My *only* complaint about
Python are not regex search, but regex search and replace operations.
Perl : s =~ s/(\w+)\s*=\s*(\d+)/$2 <= $1/g;
Python : regex.sub(s, "(\w+)\s*=\s*)\d+)", (lambda m: m.group(2)+" <=
"+m.group(1)))

I didn't try this out so there might be some syntax problems in there,
but you get the idea. Is there a 'nicer' way to do this in python?
Using 'group' and lambda functions is really quite messy. (An,
obviously, in real life usage, the replacemant function can be much
bigger...)

Why are you using the deprecated regex module?

The usual way to do this in Python would be:

import re
s = re.sub(r"(\w+)\s*=\s*(\d+)", r"\2 <= \1", s)

Comparing that with the Perl line I prefer the Python way of writing it.

 

[Skip Montanaro]

> 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.

Sure, it's more convenient but it's not thread-safe. The old regex package
used to do this. When Perl-compatible regular expressions were introduced
into Python it was removed precisely because of that limitation. As Peter
Hansen pointed out, if you want that behavior you can write it on a
per-application basis.

Skip

 

[Cameron Laird]

.
.
.

If you do stuff recursively (as I often do) or break up code into
smaller functions (as I often do) so that the functions with these
regexps get called numerous times, it can help performance to move the
compile step out of the functions.

The point is, the existence re.compile encourages people to make
regexp objects global so they only need to be compiled once, when the
module is loaded. Because of this, and especially because regexps are
prone to being used in recursive functions and such, it's dangerous to
allow them to have state.

.
.
.
I wrote the subject line for this subthread. Here's
my provisional conclusion: my past attempts to track
down claims of the "Perl is tops for string-handling"
sort generally reinforced the proposition that the
speaker simply meant, "Perl privileges REs" (and that
the speaker had no familiarity with Python, let alone
Icon or Prolog). Now I see there's a likelihood of
definite attraction to the hidden-variable, dangerous
implicitness goop so characteristic of Perl. That's
good to understand. Thanks, Carl; good analysis.

 

[Cameron Laird]

.
.
.

I actually did rewrite the routine once in PHP, but I usually find
regexps in any other language than Perl a PITA.

.
.
.
Right, and anything you can do to make that pain
concretely evident interests me. I repeat: I
have much experience of people deprecating REs
outside Perl; I'm still collecting specific
examples, to help me understand exactly what the
pain is.

 

[Peter Hansen]

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.

Which is the same tired argument that people always seem to use,
thinking it somehow justifies putting something into the core.

The "to keep people from inventing their own flavor" argument
is only useful if lots of folks are already doing this!

This is actually the first time in recent years that I can recall
that someone has complained about having to make up a new variable
(which is as good as free) to hold the result of a match. If
lots more people do it and we start getting a situation where
there are a half dozen ways to spell the same thing, *then* it's
time to consider a PEP or something, or standardizing one of
the approaches and putting it in the core.

-Peter

 

[Ville Vainio]

Cameron> my provisional conclusion: my past attempts to track
Cameron> down claims of the "Perl is tops for string-handling"
Cameron> sort generally reinforced the proposition that the
Cameron> speaker simply meant, "Perl privileges REs" (and that
Cameron> the speaker had no familiarity with Python, let alone
Cameron> Icon or Prolog). Now I see there's a likelihood of

I tend to see praises of perl string handling as an indication of just
not knowing Python. Somehow people acquire weird proconceptions (tcl
is best for quick uis, perl for string handling, ...) and refuse to
reconsider them even if the realities that originally created the
preconceptions have changed, rendering the original claim
categorically false.

BTW, nobody seems to miss Perl libs and CPAN anymore. A few years ago
most of the complaints regarding python were that perl has more
libraries. This is a good sign .

 

[Cameron Laird]

.
.
.

not knowing Python. Somehow people acquire weird proconceptions (tcl
is best for quick uis, perl for string handling, ...) and refuse to
reconsider them even if the realities that originally created the
preconceptions have changed, rendering the original claim
categorically false.

.
.
.
Oh, yes. A particular concentration of this I know is in Unix
system administration. People will sometimes stand on their
heads to do things in ways that made a lot of sense in 1994,
say, but are multiply suboptimal in 2004 (construction of fragile
shell-coded if-file-appears-in-FTP-listing algorithms when any
sane sysad supports ssh and friends, and so on). Some of the
best books are from the early '90s, and ... well, we get ourselves
into funny states.

 

[Wallclimber]

Wallclimber wrote:

Your example suggests that the Python equivalent for $1 is \1:

'1 <= a 3 <= b c = d'

I feel very stupid now. I've switched from Perl to Python about 3
years ago and always *dreaded* the used of regexen. I basically relied
on the online help to learn to use it and became convinced that I
*had* to use group.

Well, I've learned something now then. Thanks a lot!

Tom Verbeure

 

[Michael]

BTW, nobody seems to miss Perl libs and CPAN anymore. A few years ago
most of the complaints regarding python were that perl has more
libraries. This is a good sign .

IMO, CPAN is still the biggest benefit to using Python. It'd be great to
see a project to port all of CPAN functionality into standard Python
modules.

 

[Carl Banks]

.
.
.
.
.
.
I wrote the subject line for this subthread. Here's
my provisional conclusion: my past attempts to track
down claims of the "Perl is tops for string-handling"
sort generally reinforced the proposition that the
speaker simply meant, "Perl privileges REs" (and that
the speaker had no familiarity with Python, let alone
Icon or Prolog). Now I see there's a likelihood of
definite attraction to the hidden-variable, dangerous
implicitness goop so characteristic of Perl. That's
good to understand. Thanks, Carl; good analysis.

In file x.pl:

sub muck() {
$_ = "sucker\n";
}

while(<>) {
if (/^abc/) {
muck();
print $_;
}
}

Command line:

echo abcdefg | perl x.pl

Output:

sucker


I had actually thought it restored $_.
It never ceases to amaze me how bad Perl is.

 

[Steve Lamb]

Because if regexp objects are local, they have to be recompiled every
time you call the function. If you're doing that, you could be taking
a performance hit. I guess it depends on your functional style,
though. If your scripts have only one or two functions where all the
regexps are and it only gets called a few times, then it probably
won't matter too much to you.

Hrm, this gives me a hint on why one of my work scripts seems to be
running so slowly. I think I might be compiling REs every pass and it
shouldn't be.

 

[Carl Banks]

In file x.pl:

sub muck() {
$_ = "sucker\n";
}

while(<>) {
if (/^abc/) {
muck();
print $_;
}
}

Command line:

echo abcdefg | perl x.pl

Output:

sucker


I had actually thought it restored $_.
It never ceases to amaze me how bad Perl is.

Wait a minute, Perl does restore the regexp implicits.

In file x.pl:

sub muck() {
$_ = sucker;
/sucker/;
}

while(<>) {
if (/^abc/) {
muck();
print $&;
print "\n";
}
}

Command line:

echo abcdefg | perl x.pl

Output:

abc


Perl has failed to amaze me at just how bad
it is this one time.

 

[Carl Banks]

Your example suggests that the Python equivalent for $1 is \1:

'1 <= a 3 <= b c = d'

You can do that? LSNED.

 

[Martin Maney]

This is actually the first time in recent years that I can recall
that someone has complained about having to make up a new variable
(which is as good as free) to hold the result of a match. If

That's an odd way of characterizing it, since this is one of the common
forms of the FAQ more often discussed in terms of
assignment-as-operator, which used to come up about every week or so
back when I had the time to read more than an eclectic sampling of the
traffic here. The throwaway wrapper class is probably the least bad
solution - at least it can be used in thread-safe manner (1), unlike one
simply awful hack that's in the cookbook.


(1) use it as a wrapper that's instaniated locally and not shared,
which is the closest analog of how the code would go if operator= were
available, IMO&E. The bloody awful cookbook recipie is the one that
gains a little more convenience at the cost of a single globally shared
hidden variable.

 

[Fredrik Lundh]

"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

if you're referring to the "I know, I'll use regular expressions" quote, jwz
was quoting himself in that thread. from what I can tell, the original post
is here (from 1997):

http://groups.google.com/[email protected]&output=gplain

the next google hit is in this comp.lang.python-post from 1998:


http://groups.google.com/[email protected]&output=gplain

I used it again in my Standard Library book in 1999

http://effbot.org/zone/librarybook-index.htm

and it has been very popular with comp.lang.python posters and Python book
authors ever since. (some even remember to fix the broken attribution from my
post/book, but many don't, so it's easy to see who's copying from my book ;-)

</F>