To be clear, I'm -1 as well -- we just don't need it. but a few thoughts: On Mon, May 3, 2021 at 6:32 AM Steven D'Aprano <steve@pearwood.info> wrote:
If we have str comprehensions, we'd need at least two prefixes: one for
raw strings, one for regular (cooked) strings.
would we? I don't think so -- because of the other arguments made here -- a string comprehension would no longer be a string literal at all. After all, "raw strings" are not a different ty[e, they are a different literal for the same type. That is, (duh) r"this\n" creates exactly the same string as "this\\n". IIUC the proposal, a string comprehension would be: c" expr for something in an_iterable" which would mean exactly the same as: "".join(expr for something in an_iterable) and thus there IS no escaping to ignore (or process) -- the expr could contain a raw string, an_iterable could be a raw string, buit no need for a raw string comprehension. or an f-string comprehension, or ...
If it's worth doing for strings, its worth doing for bytes,
I'm not so sure about that -- bytes are far more special purpose, and there are other nifty types like bytarrays.
Another pillar of your argument is that ''.join is "unintuitive" for newbies. I don't give much weight to that argument.
I think the "".join() idiom is kinda non-intuitive -- heck I've been known, twenty years in, to absentmindedly write: a_sequence.join(",") Once in a while. And my newbie students defiantly get tripped up by this. But they find comprehensions pretty confusing too :-) so I don't think this would "solve" that minor problem. Also -- I think you made this point: "intuitiveness" is nice, but it's not the primary design goal of a feature. What I do like about str.join() is that is very clearly is a string operation.
To me, the argument that string comps could be more efficient is, at
best, a weak argument.
Also, if this were a bottleneck, "".join(a_gen_expr) could be optimized. Now that I think about it, a lot of uses of generator expressions could be optimized whenever it is iterated over right away. (Well, maybe, with the ability to rename "list" and such it would be a bit tricky). Would it be worth it to do that? I doubt it. Those aren't often in tight loops, because they ARE the loop :-)
I'm not really comfortable with having syntax that looks like a quoted
string contain executable code, but f-strings broke that trail so at least you have precedence in your favour. (Although I'm not as enamoured with f-strings as many folks.)
I am :-) But while f-strings do put executable code inside a string, they are more conceptually similar to regular string literals -- right down to having a raw version :-) However, if one wants to go with that argument, maybe a different delimter than " -- I think back ticks are available -- and even used to mean (stringify) so not so bad. But I'm still -1 -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython