feature request: a better str.endswith

[Michele Simionato]

"Raymond Hettinger" <vze4rx4y at verizon.net> wrote in message news:<NpkSa.16049$7O.14695 at nwrdny01.gnilink.net>..
> I prefer that this feature not be added.  Convenience functions
> like this one rarely pay for themselves because:
> 
>    -- The use case is not that common (afterall, endswith() isn't even
>        used that often).

This is arguable.

>    -- It complicates the heck out of the C code

Really? Of course, you are the expert. I would do it in analogy to 
"isinstance" and internally calling "ifilter" as you suggest.

>    -- Checking for optional arguments results in a slight slowdown
>        for the normal case.

Perhaps slight enough to be negligible? Of course without
implementation
we cannot say, but I would be surprised to have a sensible slowdown.

>    -- It is easy to implement a readable version in only two or three
>        lines of pure python.

Yes, but not immediately obvious. See later.

>    -- It is harder to read because it requires background knowledge
>       of how endswith() handles a tuple (quick, does it take any
>       iterable or just a tuple, how about a subclass of tuple; is it
>       like min() and max() in that it *args works just as well as
>       argtuple; which python version implemented it, etc).

I have used "isinstance" and never wondered about these
technicalities, so
I guess the average user should not be more concerned with .endswith.
  
>   -- It is a pain to keep the language consistent.  Change endswith()
>       and you should change startswith().  Change the string object and
>       you should also change the unicode object and UserString and
>       perhaps mmap.  Update the docs for each and add test cases for
>       each (including weird cases with zero-length tuples and such).

This is true for any modification of the language. One has to balance
costs and benefits. The balance is still largely subjective.
 
>   -- The use case above encroaches on scanning patterns that are
>       already efficiently implemented by the re module.

I think the general rule is to avoid regular expressions when
possible.

>   -- Worst of all, it increases the sum total of python language to be
>       learned without providing much in return.

That it is exactly what I am arguing *against*: there is no additional
learning
effort needed, since a similar feature is already present in
"isinstance"
and an user could be even surprised that it is not implemented in
.endswith.

>   -- In general, the language can be kept more compact, efficient, and
>      maintainable by not trying to vectorize everything (the recent addition
>      of the __builtin__.sum() is a rare exception that is worth it).  It is
>      better to use a general purpose vectorizing function (like map, filter,
>      or reduce).  This particular case is best implemented in terms of the
>      some() predicate documented in the examples for the new itertools module
>      (though any() might have been a better name for it):
> 
>          some(filename.endswith, ('.jpg','.jpeg','.gif','.png'))

Uhm... don't like "some", nor "any"; what about "the"?

import itertools
the=lambda pred,seq: list(itertools.ifilter(pred,seq))
for filename in os.listdir('.'):
    if the(filename.endswith, ('.jpg','.jpeg','.gif','.png')): 
        print "This is a valid image"

That's readable enough for me, still not completely obvious. The first
time,
I got it wrong by defining "the=itertools.ifilter". I had the idea
that "ifilter" was acting just as "filter", which of course is not the
case
in this example. 

>      The implementation of some() is better than the filter version because
>      it provides an "early-out" upon the first successful hit.

No point against that.
> 
> Raymond Hettinger

Michele Simionato

P.S. I am not going to pursue this further, since I like quite a lot

 if the(filename.endswith, ('.jpg','.jpeg','.gif','.png')):
    dosomething()

Instead, I will suggest this example to be added to the itertools
documentation ;)
I could also submit it as a cookbook recipe, since I think it is 
a quite useful trick.
Also, it is good to make people aware of itertool goodies 
(myself I have learned something in this thread).