perl to python

Corey Coughlin corey.coughlin at attbi.com
Thu May 13 17:25:20 EDT 2004


I do a lot of unix hacking type stuff here at work, and I understand
the wish to use the right tool for the right job and all that, and
awk, sed and perl can let you do all that quick command line stuff.  
My problem with that approach is that after I do some knock-off hack
for something, the boss will come by and say, "That's nice, but can
you do it with this tweak?" or something, and soon it has snowballed
into a full blown script.  So why bother with the one-off hacks, when
I can just write a function or something, put it in my utility object,
and it's done?  I can use it again if I need to, use it in other
scripts, call it from the python interpreter, whatever I need.  And if
(or when) I have to expand it for a more complicated purpose, nothing
could be easier.  If I stick to the traditional unix approach, I'd
probably have tools piping into tools piping into shell scripts piping
into whatever to get things done, and I'll have to check the man page
to make sure the non-standard options for the rarely used tool work,
it just winds up being a pain.
  
Here's an example from today, for instance.  There's a scratch area we
have here where files that are more than a month old are summarily
deleted.  I don't often use the area for larger projects, but I had to
for my last one, which is now getting to be around a month old.  I
still want to keep the files, so I wrote a little python script to
start from an initial directory, check the date on all the files, and
update them if necessary.  Now sure, I could have done this with some
combination of 'find', 'touch' and whatever, but then again, I have
all the function blocks I need in my python utility library, so I just
import that and it's a snap.  So I mention it to one of my co-workers,
and he now wants to use it for one of his projects, except it's using
a make-like system that will regenerate files if the dates on them get
changed relative to each other, so he wants it to take the times and
readjust them by an amount relative to the dates on each.  That's just
the kind of thing (heavy conditionals) that little unix chain commands
as solution get really ugly with, but with my script, it shouldn't be
a problem.  In fact, he's never written a script to do this because he
typically relies on the unix tool approach, and he figured it would be
too much trouble.  But now, he'll have a solution, I'll still have
mine, and if needs change in the future, it's easy to evolve.  Seems
like the right way to go to me.


Kirk Job-Sluder <kirk at eyegor.jobsluder.net> wrote in message news:<slrnca3t0e.2asc.kirk at eyegor.jobsluder.net>...
> On 2004-05-12, Ville Vainio <ville at spammers.com> wrote:
> >>>>>> "Kirk" == Kirk Job-Sluder <kirk at eyegor.jobsluder.net> writes:
> >
> >    Kirk> I've not found this to be the case due to Python's emphasis
> >    Kirk> on being explicit rather than implicit.  My emulation of
> >    Kirk> "perl -pi -e" was about 24 lines in length.  Even with the
> >    Kirk> improvement there is still 10 times as many statements where
> >    Kirk> things can go wrong.
> >
> > That's when you create a module which does the implicit looping. Or a
> > python script that evals the passed expression string in the loop.
> 
> Except now you've just eliminated portability, one of the main arguments
> for using python in the first place. 
> 
> And here is the fundamental question.  Why should I spend my time
> writing a module in python to emulate another tool, when I can simply
> use that other tool?  Why should I, as a resarcher who must process
> large quantities of data, spend my time and my employer's money
> reinventing the wheel?  
> 
> 
> >    Kirk> It is really hard to be more trivial than a complete program in one
> >    Kirk> command line.
> >
> > As has been stated elsewhere, you can do the trick on the command
> > line. The effort to create the required tools only needs to be paid
> > once.
> 
> One can do the trick one one command line in python.  However that
> command line is an ugly inelegant hack that eliminates the most
> important advantage of python: clear, easy to understand code.  In
> addition, that example still required 8 python statements compared to
> two in awk.
> 
> > However, many times it won't matter whether the whole program fits on
> > the command line. I always do a script into a file and then execute
> > it. I just prefer a real editor to command history editing if
> > something goes wrong.
> 
> Which is what I do as well.  The question is, why should I write 8
> python statements to perform a task that I can do in two using awk, or
> sed?  Why should I spend 30 minutes writing, testing and debugging a
> python script that takes 5 minutes to write in awk, or sed taking
> advantage of the implicit loops and record splitting.
> 
> > I think one should just analyze the need, implement the requisite
> > module(s) and the script to invoke the stuff in modules. The needs
> > have the habit of repeating themselves, and having a bit more
> > structure in the solution will pay off.
> 
> I think you are missing a key step.  You are starting off with a
> solution (python scripts and modules) and letting it drive your 
> needs analysis.  I don't get paid enough money to write pythonic
> solutions to problems that have already been fixed using other tools.  
> 
> > The virtual of the implicitness is still arguable.
> 
> I'll be more specific about the challenge.  Using only stock python with
> no added modules, give me a script that pretty-prints a
> character-delimted file using one variable assignment, and one function.
> 
> Here is the solution in awk:
> BEGIN { FS="\t" } 
> {printf("%s %s %s %s", $4, $3, $2, $1)}



More information about the Python-list mailing list