Home Original page

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

Andrew Barnert abarnert at yahoo.com
Thu Apr 17 23:49:32 CEST 2014 
On Apr 17, 2014, at 13:28, Ryan Hiebert <ryan at ryanhiebert.com> wrote:

> I like the idea. I agree with the assertion that has been discussed previously that a string really shouldn't be iterable.

I don't want to reopen that whole argument here, except to say that there are strong cases for both sides and nobody's managed to convince everyone to their side. At any rate, even if you don't think a string should be an iterable, it definitely _is_ one in the language as it is today.

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

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?)

> On Thu, Apr 17, 2014 at 3:14 PM, Andrew Barnert <abarnert at yahoo.com.dmarc.invalid> wrote:
>> On Apr 17, 2014, at 11:52, Alex Rodrigues <lemiant at hotmail.com> wrote:
>> 
>> > It's a fairly common problem to want to .find() or .replace() or .split() any one of multiple characters.
>> 
>> I like your solution, except for one thing. Explicitly requiring a list of arguments rather than, say, a tuple or an iterator, seems unnecessarily restrictive. However, allowing any iterable of strings doesn't work because a string is itself an iterable of strings.
>> 
>> There are a few cases where Python deals with this problem by treating tuples specially (e.g., % formatting), but I don't think anyone wants to extend that solution.
>> 
>> You could almost handle these problems with *args (replace replaces any of args[:-1] with args[-1]), except that all of them have optional parameters at the end.
>> 
>> You could have a keyword-only argument to specify an iterable of strings (in which case you can't use any positional arguments), but that's a pretty weird interface.
>> 
>> Or you could just add some new methods: split_any, replace_any, etc. But str already has a lot of methods; do we really want more?
>> 
>> I'd love to see an answer that works here, because I agree that it would make a lot of code simpler, and especially code that novices want to write.
>> _______________________________________________
>> 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/
> 
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140417/6fd31298/attachment.html>
More information about the Python-ideas mailing list