[Python-ideas] Give regex operations more sugar
Brendan Barnwell
brenbarn at brenbarn.net
Thu Jun 14 03:22:45 EDT 2018
On 2018-06-14 00:10, Steven D'Aprano wrote:
> Rather than add eight new methods, we could allow the existing string
> methods to take pattern objects as arguments. That gives us potentially:
>
> count, endswith, find, index, lstrip, partition, replace, rfind,
> rindex, rpartition, rsplit, rstrip, split, startswith, strip
>
> (15 methods) that support regex pattern objects, pretty much covering
> all the functionality of:
>
> match, fullmatch, search, split, sub, subn
>
> and then some. re.findall is redundant. That leaves (potentially) only a
> single re function to turn into a string method: finditer.
>
> How do you get the pattern object? We have three possible tactics:
>
> - import re and call re.compile;
>
> - add a compile method to str;
>
> - add special regex syntax, let's say/pattern/ for the sake of the
> argument.
Unless a special regex syntax is added, I don't see that there's much
benefit to allowing a compiled object as the argument. (And I don't
support adding special regex syntax!) The point is to be able to easily
type regular expressions. If using a pattern argument still requires
you to import re and call functions in there, it's not worth it.
In order for there to be any gain in convenience, you need to be able
to pass the actual regex directly to the string method. But there is
another way to do this beyond the ones you listed: give .find() (or
whatever methods we decide should support regexes) an extra boolean
"regex" argument that specifies whether to interpret the target string
as a literal string or a regex.
I'm not sure why I'm arguing this point, though. :-) Because I
actually agree with you (and others on this thread) that there is no
real need to make regexes more convenient. I think importing the re
module and using the functions therein is fine. If anything, I think
the name "re" is too short and cryptic and should be made longer!
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
More information about the Python-ideas
mailing list