On Sat, May 01, 2021 at 03:05:51AM -0000, Valentin Berlier wrote:
> It's kind of weird that people seem to be missing the point about
> this. Python already has comprehensions for all the iterable builtins
> except strings.
No it doesn't.
I count 15 builtin iterables, only three have comprehensions.
> The argument that we can already do this with the "".join()
> idiom is backwards. It's something we have to do _because_ there's no
> way to write a string comprehensions directly. Comprehensions express
> intent.
Okay. What string comprehension do I write to express my intent to write
a string containing words separated by commas?
What string comprehension do I write to express my intent to write a
string containing lines separated by newlines?
What string comprehension do I write to express my intent to write a
string containing substrings separated by ' - ' (space, hyphen, space)?
`str.join` can express the intent of every single one of those, as well
as the intent to write a string containing substrings separated by the
empty string.
> Joining a generator expression with an empty string doesn't
> convey the intent that you're building a string where each character
> is derived from another iterable.
Of course it does. What else could `''.join(expression)` mean, if not to
build a string with the substrings derived from expression separated by
the empty string?
> Also I haven't seen anyone acknowledge the potential performance
> benefits of string comprehensions. The "".join() idiom needs to go
> through the entire generator machinery to assemble the final string,
> whereas a decent implementation of string comprehensions would enable
> some pretty significant optimizations.
Do you know what's worse than premature optimization? Accepting a new
special-case language feature on the basis that, maybe some day, it
might possibly enable a premature optimization.
If you're going to claim a micro-optimization benefit, I think you need
more than just to hand-wave that "a decent implementation" would allow
it. Let's start with the simplest case:
c'substring for substring in expression'
What optimizations are available for that?
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/4LX5OHCTPVBACLFTXVSXCGRCAZZA6VWR/
Code of Conduct: http://python.org/psf/codeofconduct/
