Raw string substitution problem
in [Python]
|
Prev: Odd json encoding erro
Next: Subclassing RegexObject
From: Lie Ryan on 18 Dec 2009 13:31 On 12/19/2009 4:59 AM, Alan G Isaac wrote: > On 12/18/2009 12:17 PM, MRAB wrote: >> In simple cases you might be replacing with the same string every time, >> but other cases you might want the replacement to contain substrings >> captured by the regex. > > > Of course that "conversion" is needed in the replacement. > But e.g. Vim substitutions handle this fine without the > odd (to non perlers) handling of backslashes in replacement. > > Alan Isaac Short answer: Python is not Perl, Python's re.sub is not Vim's :s. Slightly longer answer: Different environments have different need; vim-ers more often needs to escape with just a plain text. All in all, the decision for default behaviors are often made so that less backslash will be needed for the more common case in the particular environment.
From: Gregory Ewing on 18 Dec 2009 19:21 MRAB wrote: > In simple cases you might be replacing with the same string every time, > but other cases you might want the replacement to contain substrings > captured by the regex. But you can give it a function that has access to the match object and can produce whatever replacement string it wants. You already have a complete programming language at your disposal. There's no need to invent yet another mini-language for the replacement string. -- Greg
From: MRAB on 18 Dec 2009 21:24 Gregory Ewing wrote: > MRAB wrote: > >> In simple cases you might be replacing with the same string every >> time, but other cases you might want the replacement to contain >> substrings captured by the regex. > > But you can give it a function that has access to the match object > and can produce whatever replacement string it wants. > > You already have a complete programming language at your disposal. > There's no need to invent yet another mini-language for the > replacement string. > There's no need for list comprehensions either, but they're much-used shorthand.
From: Steven D'Aprano on 18 Dec 2009 22:29 On Sat, 19 Dec 2009 02:24:00 +0000, MRAB wrote: > Gregory Ewing wrote: >> MRAB wrote: >> >>> In simple cases you might be replacing with the same string every >>> time, but other cases you might want the replacement to contain >>> substrings captured by the regex. >> >> But you can give it a function that has access to the match object and >> can produce whatever replacement string it wants. >> >> You already have a complete programming language at your disposal. >> There's no need to invent yet another mini-language for the replacement >> string. >> > There's no need for list comprehensions either, but they're much-used > shorthand. The same can't be said for regex replacement strings, which are far more specialised. And list comps don't make anything *harder*, they just make things easier. In contrast, the current behaviour of regex replacements makes it difficult to use special characters as part of the replacement string. That's not good. -- Steven
From: Rhodri James on 19 Dec 2009 19:07
On Fri, 18 Dec 2009 17:58:08 -0000, Alan G Isaac <alan.isaac(a)gmail.com> wrote: > On 12/17/2009 7:59 PM, Rhodri James wrote: >> "re.compile('a\\nc')" passes a sequence of four characters to >> re.compile: 'a', '\', 'n' and 'c'. re.compile() then does it's own >> interpretation: 'a' passes through as is, '\' flags an escape which >> combined with 'n' produces the newline character (0x0a), and 'c' passes >> through as is. > > > I got that from MRAB's posts. (Thanks.) > What I'm not getting is why the replacement string > gets this particular interpretation. What is the payoff? So that the substitution escapes \1, \2 and so on work. -- Rhodri James *-* Wildebeeste Herder to the Masses |