sed to python: replace Q

[Dan Stromberg]

On Tue, 06 May 2008 14:55:07 +0000, Raymond wrote:

>>Another approach is to use the split() function in "re" module.
> 
> Ah ha, thar's the disconnect.  Thanks for all the pointers, my def is
> now working.  Still don't understand the logic behind this design
> though. I mean why would any programming language have separate search
> or find functions, one for regex and and another for non-regex based
> pattern matching?
> 
> Aren't sed, awk, grep, and perl the reference implementations of search
> and replace?  They don't have non-regex functions, why does Python?
> Wouldn't it be a lot simpler to use a flag, like grep's '-f', to change
> the meaning of a search string to be literal?
> 
> My other gripe is with the kludgy object-oriented regex functions.
> Couldn't these be better implemented in-line?  Why should I, as a coder,
> have to 're.compile()' when all the reference languages do this at
> compile time, from a much more straightforward and easy to read in-line
> function...
> 
> Raymon

Hm.  Are regex's first class citizens in these languages, like they are 
in python?

And from a language design perspective, isn't it much cleaner to put 
regex's into just another portion of the runtime rather than dumping it 
into the language definition proper?

It does actually make sense - to have a string method do a string thing, 
and to have a regex method do a regex thing.  And while command line 
options are pretty nice when done well, there's nothing in particular 
stopping one from using arguments with defaults in python.

I'm good with sed and grep, though I never got into awk much - perhaps a 
small mistake.  When it came to perl, I skipped it and went directly to 
python, and have never regretted the decision.  Python's got a much more 
coherent design than perl, most certainly, and more than sed as well.  
awk's not that bad though.  And grep's nice and focused - I quite like 
grep's design.