[Python-ideas] Give regex operations more sugar

Steven D'Aprano steve at pearwood.info
Thu Jun 14 04:02:58 EDT 2018


On Thu, Jun 14, 2018 at 12:22:45AM -0700, Brendan Barnwell wrote:

> 	Unless a special regex syntax is added, I don't see that there's 
> 	much benefit to allowing a compiled object as the argument.

Fair enough -- I'm not convinced that this proposal is either desirable 
or necessary either, I'm just suggesting what we *could* do if we choose 
to. But I'll admit that I'm biased: I find all but the simplest regexes 
virtually unreadable and I'm very antipathetic to anything which 
encourages the use of regexes. (Even though I intellectually know that 
they're just a tool and we shouldn't blame regexes for the abuses some 
people put them too.)


[...]
> 	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.

Guido has a guideline (one I agree with): no constant bool arguments.

If you have a method or function that takes a flag that swaps between 
two modes, and in practice the flag is only ever (or almost only ever) 
going to be given as a literal, then it is better to split the function 
into two distinctly named functions and forego the flag.

*Especially* if the flag simply swaps between two distinct 
implementations with little or nothing in common.


> 	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!

Heh, even I don't go that far :-)


-- 
Steve


More information about the Python-ideas mailing list