How's ruby compare to it older brother python

[Steve Lamb]

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.

 

[Paramjit Oberoi]

getting dynamic HTML pages up and running quickly. Perl is great for
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

 

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

 

[Brandon J. Van Every]

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

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+Y0CpvERAge8AJ4s6qDPoCVB6BFrBjFOYfhPMTkFoACfcfdZ
6d2x9KAJGe+T67W6W4Y1zVI=
=j8qP
-----END PGP SIGNATURE-----

 

[Erik Max Francis]

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

 

[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

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

 

[Asun Friere]

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

 

[Roy Smith]

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?

 

[Wilk]

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

 

[Peter Hansen]

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/[email protected]

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

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]

.
.
.

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

Skip

"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/s=2472/uni1037388368795/ >.

 

[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

 

[Cameron Laird]

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.