How's ruby compare to it older brother python

[Michele Dondi]

Re: Is Perl *that* good? (was: How's ruby compare to it older brother python)

ùOn Mon, 26 Apr 2004 16:55:02 -0400, "Ruby Tuesdays"
<NoSpamPlease_r ubytuzdaiz@yaho o.com> wrote:
[color=blue]
>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.[/color]

Huh?!?


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

[Tad McClellan]

Re: Is Perl *that* good? (was: How's ruby compare to it older brother python)

Michele Dondi <bik.mido@tisca linet.it> wrote:[color=blue]
> ùOn Mon, 26 Apr 2004 16:55:02 -0400, "Ruby Tuesdays"
><NoSpamPlease_ rubytuzdaiz@yah oo.com> wrote:
>[color=green]
>>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.[/color]
>
> Huh?!?[/color]


Simply make a killfile entry and move on.


--
Tad McClellan SGML consulting
tadmc@augustmai l.com Perl programming
Fort Worth, Texas

[Carl Banks]

Re: Is Perl *that* good?

Paramjit Oberoi wrote:[color=blue]
>
>[color=green]
>> 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[/color]
>
> 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(l ine)
> if (m):
> xyz = m.group('xyz')
>
> It would be much easier to do:
>
> if myregex.match(l ine):
> xyz = myregex.lastm.g roup('xyz')
>
> Having to introduce a new variable name for a match object just
> muddles the code unnecessarily in common regex usage scenarios.[/color]


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(l ine):
xyz = (subprocess(lin e[myregex.lastm.e nd():])
+ myregex.lastm.g roup(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]

Re: Is Perl *that* good?

Carl Banks <imbosol@aerojo ckey.invalid> wrote:[color=blue]
> 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(l ine):
> xyz = (subprocess(lin e[myregex.lastm.e nd():])
> + myregex.lastm.g roup(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.[/color]

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]

Re: Is Perl *that* good?

Roy Smith wrote:[color=blue]
>
>
> Carl Banks <imbosol@aerojo ckey.invalid> wrote:[color=green]
>> 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(l ine):
>> xyz = (subprocess(lin e[myregex.lastm.e nd():])
>> + myregex.lastm.g roup(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.[/color]
>
> I don't see that this is any worse than any other stateful object.[/color]

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

[Roy Smith]

Re: Is Perl *that* good?

In article <ECCjc.30580$Vp 5.25085@fe2.col umbus.rr.com>,
Carl Banks <imbosol@aerojo ckey.invalid> wrote:
[color=blue]
> 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.[/color]

I don't see why regexps are usually global. Nor do I see why exposing
the compiler encourages them to be global, or why making them local
should result in a performance hit.

I do a lot of regex work. I just looked over a bunch of scripts I
happen to have handy and only found one where I used global regexp
objects. In that script, the regexps were only used in a single
routine, so moving them down in scope to be local to that routine would
have made more sense anyway. Looking back at the code, which I wrote
several years ago, I have no idea why I decided to make them global.

[Asun Friere]

Re: Is Perl *that* good?

Skip Montanaro <skip@pobox.com > wrote in message news:<mailman.4 9.1083084698.25 742.python-list@python.org >...
[color=blue]
> 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).[/color]

Sure.
[color=blue]
> 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.[/color]

What I meant is that if it involves lots of regexp I'd probably use
Perl If it involved lots of regex AND object orientation, I wouldn't
consider Perl.
[color=blue]
> 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.[/color]

It's good for the soul to shift your mental gears every now and then.

[Carl Banks]

Re: Is Perl *that* good?

Roy Smith wrote:[color=blue]
> In article <ECCjc.30580$Vp 5.25085@fe2.col umbus.rr.com>,
> Carl Banks <imbosol@aerojo ckey.invalid> wrote:
>[color=green]
>> 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.[/color]
>
> I don't see why regexps are usually global. Nor do I see why exposing
> the compiler encourages them to be global, or why making them local
> should result in a performance hit.[/color]

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.

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.


[color=blue]
> I do a lot of regex work. I just looked over a bunch of scripts I
> happen to have handy and only found one where I used global regexp
> objects. In that script, the regexps were only used in a single
> routine, so moving them down in scope to be local to that routine would
> have made more sense anyway. Looking back at the code, which I wrote
> several years ago, I have no idea why I decided to make them global.[/color]

Well, that's fine. For the reasons I've stated, I think there are
good reasons to not do it the way you did it.


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

Re: Is Perl *that* good?

Carl Banks <imbosol@aerojo ckey.invalid> wrote:[color=blue]
> especially because regexps are
> prone to being used in recursive functions and such[/color]

Why are regexps prone to being used in recursive functions?

[Paramjit Oberoi]

Re: Is Perl *that* good?

>> If only compiled regular expression objects allowed easy access to the[color=blue][color=green]
>> last match object, python regxes would become significantly more
>> convenient. For example, today you have to write:[/color]
>
> 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:[/color]

I agree that that's a good reason...

So: to make regular expressions convenient, it should be possible to use
them without necessarily declaring a variable for the regular expression
object or the match objects. The former is fairly easy; the latter is
not.

The match object needs to have local scope; but, a function cannot access
the caller's locals without mucking around with sys._getframe() . Is there
any other way of injecting objects into the caller's namespace? Are there
any objects that exist per-frame that could be co-opted for this purpose?

I suppose a convenience module that uses sys._getframe() could be written,
but I don't think it would be suitable for the standard library. Of
course, once we get decorators, it would be possible to munge functions to
make them more amenable to regexes... but then, we don't want such hackery
in the standard library either.

Question about decorators: are they only going to be for methods, or for
all functions?

[Paramjit Oberoi]

Re: Is Perl *that* good?

>> if myregex.match(l ine):[color=blue][color=green]
>> xyz = myregex.lastm.g roup('xyz')[/color]
>
> 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:[/color]

Another thing in perl that makes regexes convenient is the 'default'
variable $_. So, maybe the following could be done:

line_a = re.compile(...)
line_b = re.compile(...)

rx = re.context()
for rx.text in sys.stdin:
if rx(line_a).matc h():
total += a_function() + rx[1]
elif rx(r'^msg (?P<text>.*)$') .match():
print rx['text']
elif rx(line_b).matc h(munge(text)):
print 'munged text matches'

// similarly rx.{search, sub, ...}

But, as Peter Hansen pointed out, maybe this is more suited to a personal
utility module... What are the considerations for whether something
should or shouldn't be in the standard library?

[Michael]

Re: Is Perl *that* good?

[color=blue]
>Regular expressions are like duct tape. They may not be the best tool
>for everything, but they usually get the job done.
>
>[/color]
Until you are in the middle of a vital project with a limited time to
get the job done and suddenly all your duct tape starts to twist
together incorrectly. :)

[Carl Banks]

Re: Is Perl *that* good?

Roy Smith wrote:[color=blue]
> Carl Banks <imbosol@aerojo ckey.invalid> wrote:[color=green]
>> especially because regexps are
>> prone to being used in recursive functions and such[/color]
>
> Why are regexps prone to being used in recursive functions?[/color]

Prone was probably a bit too strong a word, but using regexps inside a
recursive function is far from an obscure use. It can show up in
functions that parse arbitrarily nested text, which typically use
recursion to handle the arbitrarily nested part.


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

[S Koppelman]

Re: Is Perl *that* good?

Leif B. Kristensen wrote:[color=blue]
> Cameron Laird rose and spake:[color=green]
>>In article <iL3jc.232$Yc.2 330@news4.e.nsc .no>,
>>Leif B. Kristensen <junkmail@solum slekt.org> wrote:
>>[color=darkred]
>>>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.)[/color]
>>.
>>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.[/color]
>
> 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.....
>
> Here's a small sample:
>
> $str =~ s/HN/N/g; # John --> JON
> $str =~ s/TH/T/g; # Thor --> TOR ....
>
> [snip]
>
> 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.[/color]

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

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

-sk

[Wallclimber]

Re: Is Perl *that* good?

> Asun> Probably the only time I would reach for Perl rather than for[color=blue]
> 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.[/color]

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