I started seeing this, as the objecting people are putting, something that is really outside of the scope. But it just did occur to me that having to use str.join _inside_ an f-string expression is somewhat cumbersome I mean, think of a typical repr for a sequence class: return f"MyClass({', '.join(str(item) for item in self) } )" So, maybe, not going for another kind of string, or string comprehensions, but rather for a formatting acceptable by the format-mini-language that could do a "map to str and join" when the item is a generator? This maybe would: suffice the O.P. request, introduce no fundamental changes in the way we think the language, _and_ be somewhat useful. The example above could become return f"MyClass({self:, j}" The "j" suffix meaning to use ", " as the separator, and map the items to "str" - this, if the option is kept terse as the other indicators in the format mini language, or could maybe be more readable (bikeshed at will) . (Other than that, I hope it is clear I am with Steven, Chris, Christopher et al. on the objections to the 'string comprehension' proposal as it is) On Sat, 1 May 2021 at 17:36, Christopher Barker <pythonchb@gmail.com> wrote:
On Fri, Apr 30, 2021 at 11:15 PM Valentin Berlier <berlier.v@gmail.com> wrote:
You could say that f-strings are redundant because they can't do anything that str.format can't, but they make it possible to shave off the static overhead of going through python's protocols and enable additional optimizations.
But that was not the primary motivator for adding them to the language.
Nor is it the primary motivator for using them. I really like f-strings, and I have never even thought about their performance characteristics.
With regard to the possible performance benefits of “string comprehensions”: Python is already poorly performant when working with strings character by character. Which is one reason we have nifty string methods like .replace() and .translate. (And join).
I’d bet that many (most?) potential “string comprehensions” would perform better if done with string methods, even if they were optimized.
Another note that I don’t think has been said explicitly— yes strings are Sequences, but they are a very special case in that they can contain only one type of thing: length-1 strings. Which massively reduces the possible kinds of comprehensions one might write, and I suspect most of those are already covered by string methods.
[actually, I think this is a similar point as that made by David Mertz)
-CHB
-- Christopher Barker, PhD (Chris)
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Z3J727... Code of Conduct: http://python.org/psf/codeofconduct/