New function proposal: string.from_iterable(iterable [,map_function])

[4144abea-f603-4610-9c51-7d9a8765ffdc]

BPO	23179
Nosy	@rhettinger, @ezio-melotti, @bitdancer, @MojoVampire, @youtux
Files	string.from_iterable.patch: The proposed enhancement

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['type-feature', 'library'] title = 'New function proposal: string.from_iterable(iterable [,map_function])' updated_at = user = 'https://github.com/youtux' ``` bugs.python.org fields: ```python activity = actor = 'rhettinger' assignee = 'none' closed = True closed_date = closer = 'r.david.murray' components = ['Library (Lib)'] creation = creator = 'youtux' dependencies = [] files = ['37619'] hgrepos = [] issue_num = 23179 keywords = ['patch'] message_count = 6.0 messages = ['233554', '233555', '233556', '233557', '233559', '233567'] nosy_count = 5.0 nosy_names = ['rhettinger', 'ezio.melotti', 'r.david.murray', 'josh.r', 'youtux'] pr_nums = [] priority = 'normal' resolution = 'rejected' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue23179' versions = ['Python 3.4', 'Python 3.5'] ```

[4144abea-f603-4610-9c51-7d9a8765ffdc]

I would like to suggest a new string function/constructor: string.from_iterable(iterable [,map_function])

I think that the behaviour is intuitive: given an iterable, it construct a string using its element by apply a map_function, if provided, to each one of them. After that the str() constructor will be applied to each element in any way, to ensure that effectively an iterable of strings is used.

Of course I do not expect that you will accept this patch, but I think this really is a missing piece of the python library.

You can argue that I could just use "".join(iterable) but in my opinion there are two problems: 1) if any of the elements of iterable is not a str instance, it will fail miserably; 2) this is not very pythonic.

This issue is meant to be an idea for the python maintainers, so I did not write the corresponding [Doc/libary/string.rst](https://github.com/python/cpython/blob/main/Doc/libary/string.rst) documentation, but if you are interested I could do it.

Thank you people for your amazing work.

[ezio-melotti]

You should propose this to the python-ideas mailing list. FWIW, if this is accepted, I would use str as default map_function.

[bitdancer]

Thanks for wanting to contribute. However, I don't see why this function would be beneficial. As indicated by the patch, it is simply

''.join(str(map_function(x)) for x in iterable)

but without the inherent flexibility of the above formulation. Which looks pretty Pythonic to my eyes :).

We often say "not every one line expression deserves to be a function."

But yes, python-ideas would be the appropriate forum to discuss such a thing. This issue can be reopened if you get consensus that it is a valuable addition.

[99ffcaa5-b43b-4e8e-a35e-9c890007b9cd]

I'll note: "".join(map(str, iterable)) will solve problem #1. It's fast, uses existing built-ins, and is relatively intuitive. I know map is sometimes considered Pythonic, but "".join(str(x) for x in iterable) is an equally effective, if somewhat slower, alternative that can't be called un-Pythonic.

I have no idea why you think "".join(iterable) is not Pythonic, it's *the* way to join strings into a single string. Fast, direct, simple. string.from_iterable seems like a silly way to do what "".join(map(INSERTFAVORITEFUNCTIONHERE, iterable)) does already, for no gain.

[99ffcaa5-b43b-4e8e-a35e-9c890007b9cd]

Correction: I know map is sometimes considered *un-Pythonic

[rhettinger]

I concur with Josh and David. We already have a way to do it and there doesn't seem to be anything here that would warrant further growth of the already large number of string methods.