Larry Price wrote:
> > Parsing the input was easier in Perl. I used the
> > exact same regular expressions in both, but the Perl
> > seemed a lot easier.
>
> Is it because Python\'s regex flavor require\'s you
> \"escape\" everything\?
No, Perl does that too.
But compare this Perl:
/^\[(\d+)\:(\d+)\:(\d+)\]/ and ($o, $t) = ($t, $1 * 3600 + $2 * 60 + $3);
with this Python:
timestamp = re.match(r'\[(\d+)\:(\d+)\:(\d+)\]', line)
if timestamp:
hr, min, sec = [int(n) for n in timestamp.groups()]
o, t = t, (hr * 60 + min) * 60 + sec
To me, the Perl is more straightforward. "If the current input
matches this expression, then do these assignments."
The Python requires explicit naming of the input line, explicit naming
of the fact that the match succeeded, an explicit string to int
conversion, and explicit naming of the matched substrings. And
timestamp.groups() is counterintuitive as a way to access the
substrings.
Perl: one line, no extra names.
Python: four lines, four extra names (timestamp, hr, min, and sec).
OTOH, I can see that a non-Python programmer could read the Python
easier than a non-Perl programmer could read the Perl. (What's <>?
What's $1? What string is the regexp matching?)
> > First time I've ever used the print statement in a nontrivial
> > way. Worked pretty well in this case. Wouldn't be as clean
> > if I didn't have whitespace around each calculated value.
>
> One feature of python that I've become quite fond of lately is the ability
> to hand the string interpolation operator a dictionary and have it
> properly format stuff without messing around with print tuples.
Yeah, there's a minimum format complexity for which that's worthwhile.
I didn't judge it worthwhile here.
I think it would go like this.
out_strings = {
len: len(ftimes),
mean: time_format(ftimes.mean()),
min: time_format(ftimes.minimum()),
max: time_format(ftimes.maximum()),
std_dev: time_format(ftimes.std_deviation())
}
print "%{len}s frames" % out_strings
print "fastest: %{min}s" % out_strings,
# ...
Right?
Actually, that looks pretty good. I like it.
> > I'm still new to Python. If you can see ways to write it better,
> > I'd appreciate the criticism. If you can see ways to write the
> > Perl better, that's cool too.
>
> O, kbob, stop being so darn modest, you're a better programmer than most
> of us on this list even aspire to be. I learn something new whenever you
> post code to the list, this time that a. I can read more perl than I
> realized (or maybe this perl is more lucid than most) b. I've been
> developing bad habits even in python, and not structuring my code enough.
It's not modesty, it's a desire to learn. *
But thanks for the compliment.
* The big lesson I learned today: Linux preserves signal masks across
execve(). So the prudent programmer must explicitly unmask any
signal he plans to use. Who knew? Have you ever seen code that
does the unmask? (You can imagine the debugging session that
preceded the lesson. (-: )
--
Bob Miller K<bob>
kbobsoft software consulting
http://kbobsoft.com [EMAIL PROTECTED]
