[Python-ideas] fnmatch.filter_false

[tritium-list at sdamon.com]

> -----Original Message-----
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon.com at python.org] On Behalf Of Steven D'Aprano
> Sent: Wednesday, May 17, 2017 9:01 PM
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] fnmatch.filter_false
> 
> On Wed, May 17, 2017 at 12:14:05PM -0400, Alex Walters wrote:
> > Fnmath.filter works great.  To remind people what it does, it takes an
> > iterable of strings and a pattern and returns a list of the strings that
> > match the pattern.  And that is wonderful
> >
> > However, I often need to filter *out* the items that match the pattern
(to
> > ignore them).  In every project that I need this I end up copying the
> > function out of the fnmatch library and adding 'not' to the test clause.
> 
> At the cost of a slight inefficiency, you could use the pure Python
> equivalent given in the docs:
> 
> https://docs.python.org/3/library/fnmatch.html#fnmatch.filter
> 
> 
> fnmatch.filter(names, pattern)
> 
>     Return the subset of the list of names that match pattern. It is
>     the same as [n for n in names if fnmatch(n, pattern)], but implemented
>     more efficiently.
> 
> So your filter_false is:
> 
>     [n for n in names if not fnmatch(n, pattern)]
> 
> which avoids the need for the copy-and-paste anti-pattern.

I ran a test on the same dataset using listcomps.  The modified version of
filter is still 22.<some noise>, the unmodified version is still 19.<some
noise>.  However the listcomp method is 41.<some noise>.  That performance
is important, at least to me.  Before you ask, yes, I have profiled my code,
and filtering is a bottleneck.

> 
> Otherwise, I would support:
> 
> - filter_false
> 
> - or a glob symbol to reverse the sense of the test, e.g. ~ or !
>   as the first character;
> 
> 
> but I dislike functions that take boolean arguments to change their
> behaviour. It's not a 100% hard and fast rule, but in general I prefer
> to avoid functions that take a constant bool argument:
> 
> # rather than this:
> function(important_args, True)
> function(important_args, False)
> 
> # use this:
> function(important_args)
> function_false(important_args)
> 
> (although there may be exceptions).
> 

That is a fair enough argument.  In moderate defense of the code I posted
earlier, I did make the inversion variable keyword only.

> 
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/