[Python-ideas] str.find() and friends support a lists of inputs

[Alex Rodrigues]

Currently .endswith() and .startswith() accept a str, unicode, or tuple and use the tuple exactly in the same way this would. That might not be a bad place to start when thinking about which types to support.

Date: Thu, 17 Apr 2014 17:21:07 -0500
Subject: Re: [Python-ideas] str.find() and friends support a lists of inputs
From: ryan at ryanhiebert.com
To: abarnert at yahoo.com
CC: abarnert at yahoo.com.dmarc.invalid; lemiant at hotmail.com; python-ideas at python.org

On Thu, Apr 17, 2014 at 4:49 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

On Apr 17, 2014, at 13:28, Ryan Hiebert <ryan at ryanhiebert.com> wrote:
Because of that, I think that explicitly checking if it is str, and if not, using it as an iterator, would be appropriate.
You mean as an iterable, not as an iterator, right?
Yes. 

But anyway, that would be very odd. Is there anywhere else in the stdlib that strings are treated specially and not iterated over? (As I mentioned before, there are cases where tuples are treated specially, but I don't think anyone considers that a good thing, or wants to take it any further.)

Also, you have to be careful about what you mean by "string". Does that mean str, str or any subclass, anything that quacks like a string in a certain context, ...? And then, what's the parallel definition for bytes and bytearray methods? (Maybe there should be ABCs for String, MutableString, ByteString, and MutableByteString to provide a better answer to those questions?)

How about defining it as "anything that currently works in those contexts"? Currently, it allows str and subclasses, but not bytes, because they cannot be converted implicitly to str. So, try it how it works now, and if that fails, try using it as an iterable.

Are there similar methods on bytes which might make that definition confusing?
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140417/82477a5c/attachment.html>