To be clear, I'm -1 as well -- we just don't need it. but a few thoughts:
> 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