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 <python...@gmail.com> wrote: > > > On Fri, Apr 30, 2021 at 11:15 PM Valentin Berlier <berlie...@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-le...@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/Z3J727MCT46XPDUAEQLH7ZWEKO7QZKTX/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/OX7F5N5KPOEBD27OBZAGWQBTA3SDJNAO/ Code of Conduct: http://python.org/psf/codeofconduct/