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 <st...@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
_______________________________________________
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/PSMJVDMX4NXB7A4VKNMHI5I4VYVS4NJL/
Code of Conduct: http://python.org/psf/codeofconduct/
