On 2021-04-30 11:14, David Álvarez Lombardi wrote:
To me, it is hard to see how any argument against this design (for
anything other than implementation-difficulty or something along these
lines) can be anything but an argument against iter comprehensions in
general... but if someone disagrees, please say so.
The difference between your proposal and existing comprehensions is
that strings are very different from lists, dicts, sets, and generators
(which are the things we currently have comprehensions for). The syntax
for those objects is Python syntax, which is strict and can include
expressions that have meaning that is interpreted by Python. But
strings can contain *anything*, and in general (apart from f-strings)
their content is not parsed by Python. You can't do this:
[wh4t3ver I feel like!!! okay?^@^&]
But you can do this:
"wh4t3ver I feel like!!! okay?^@^&"
This means that the way people think about and visually comprehend
strings is quite different from other Python types. You propose to have
the string delimiters now contain actual Python code that Python will
parse and run, but this isn't what people are used to seeing between
quote marks.
I think the closest existing thing to your string comprehensions is not
any existing comprehension, but rather f-strings, which are the one
place where Python does potentially parse and execute code in a string.
However, f-strings are different in notable ways.
First, the code in f-strings is delimited (by curly braces), so it is
visually distinguished from "freeform" text within the string. Second,
f-strings do not restrict the normal usage of strings for freeform text
content (apart from making the curly brace characters special). So
`f"wh4t3ver I feel like!!! okay?^@^&"` is a valid f-string just like
it's a valid string. In your proposal (I assume), something like
`c"item for item in other_seq and then the string text continues here"`
would have to be a syntax error. That is, unlike f-strings (or any
other existing kind of string), the string comprehension would "claim"
the entire string and you could no longer put normal string content in
there.
Your proposal is focusing on strings as iterables and drawing a
parallel with other kinds of iterables for which we have comprehensions.
But strings aren't like other iterables because they're primarily
vessels for freeform text content, not structured data.
For the same reason, string comprehensions are likely to be less
useful. I would look doubtfully on code that tried to do anything
complex in a string comprehension, in the same way that I would look
doubtfully on code that used f-strings with huge, complex expressions.
It would be more readable to do whatever data preparation you need to do
before creating the string and then use a simpler final step to create
the string itself.
Also, string comprehensions would only facilitate the creation of
simple "linear" strings which draw their content sequentially from
iterables. I find that in practice, if I want to create a string,
programmatically, I'm not doing that. Rather, I'm pulling disparate
content from different places and putting it together in a template-like
fashion, in the way that f-strings or str.format() facilitate. So I
don't think this proposal would have much practical use in string creation.
So overall I think your proposed string comprehensions would tend to
make Python code less readable in the relatively rare cases where they
were useful at all.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/B2SY2UI7FNOBTCZILYEHPXECJNJ2YBLH/
Code of Conduct: http://python.org/psf/codeofconduct/
