Closed 4144abea-f603-4610-9c51-7d9a8765ffdc closed 9 years ago
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.
You should propose this to the python-ideas mailing list. FWIW, if this is accepted, I would use str as default map_function.
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.
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.
Correction: I know map is sometimes considered *un-Pythonic
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.
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']
```