[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