p.replace(p.re(...), ...) produces unexpected results if there are no matches, or multiple (but "different") matches

[GoogleCodeExporter]

What steps will reproduce the problem?
echo '123' | pyp "p.replace(p.re('BLAH'), '_')"
echo '123' | pyp "p.replace(p.re('[123]'), 'x')"

What is the expected output? What do you see instead?

EXPECTED:
123
xxx

GOT:
_1_2_3_
x23

What version of the product are you using? On what operating system?
2.12, Linux - Fedora 19 (Python 2.7)

Please provide any additional information below.
I tried the above because the docs specifically say: "works great with 
p.replace(p.re(REGEX),STR)".  However, as the above examples indicates, it can 
lead to some unexpected results.  However, since you wish to preserve the 
"normal" behavior of p.re, I propose a new / separate method for doing regexp 
based search-replace, ie, something like:

p.re_replace
or
p.re_sub

...which would simply wrap re.sub

Original issue reported on code.google.com by [email protected] on 21 Jan 2014 at 6:42

[GoogleCodeExporter]

Actually, to match the existing convention of:

keep
rekeep
lose
relose

...I think it should be named

rereplace

Original comment by [email protected] on 21 Jan 2014 at 6:44

[GoogleCodeExporter]

Adding a patch to add the proposed rereplace... with it, if you run:

echo '123' | pyp "p.rereplace('BLAH', '_')"
echo '123' | pyp "p.rereplace('[123]', 'x')"

...you get the "EXPECTED" results given above...

Original comment by [email protected] on 21 Jan 2014 at 6:52

Attachments:

• pyp_rereplace.patch

[GoogleCodeExporter]

Oh, and if this patch is accepted, should probably update the docs / wiki to 
suggest people use p.rereplace, instead of p.replace(p.re(), ...)

Original comment by [email protected] on 21 Jan 2014 at 6:53

[GoogleCodeExporter]

thanks for this. sorry for the late reply. this made it in. I'll be rolling out 
a beta in the next few days.

t

Original comment by [email protected] on 9 Feb 2015 at 10:29

[GoogleCodeExporter]

Cool, glad to hear it made it in! =)

Original comment by [email protected] on 9 Feb 2015 at 11:57