On Sun, May 02, 2021 at 10:57:59PM -0400, David Álvarez Lombardi wrote:
> I really appreciate all the feedback and all of the thought put into this
> idea. I wanted to make a couple of comments on some of the responses and
> provide my current thoughts on the idea.
>
> --- Responses to comments ---
>
> > *All* others?
> >
> > Tuple, frozenset, bytes, bytearray, memoryview, enumerate, range, map, zip,
> > reversed and filter suggest otherwise.
>
> Yes. You are right. My use of "all" was technically incorrect. But I think
> it is *very* disingenuous to pretend that these types play anywhere near as
> central a role in python use as list, dict, and set... especially for
> newbies.
I didn't say anything about those other iterable types playing a central
role. Although now that you mention is, I *do* think that bytes, tuple,
enumerate, range and zip are pretty central, even for newbies.
> Please try to provide contentful comments instead of "gotchas".
One of your central arguments was that str is the only builtin iterable
that doesn't have a comprehension form. That argument doesn't stand up
to scrutiny.
It doesn't even stand up if we weaken the argument to common,
newbie-friendly, builtin containers with dedicated syntax: as well as
str, there are bytes and tuple.
No matter how you count them, the comprehension types (dict, set and
list) don't exceed 50% of the candidates.
If we have str comprehensions, we'd need at least two prefixes: one for
raw strings, one for regular (cooked) strings. If it's worth doing for
strings, its worth doing for bytes, which likewise would need two
prefixes.
Another pillar of your argument is that ''.join is "unintuitive" for
newbies. I don't give much weight to that argument. Especially not for
newbies.
Seriously, why do we think that people with no programming experience,
who might not even know the difference between print and return or a
variable and a constant, are the gold standard in being able to
recognise a good language API?
It breaks my brain, and my heart, when people argue that "it's
intuitive" trumps "I thought really hard and carefully about this, and
this is a better way". This is why we can't have nice things :-(
Anyway, lets go back to string comprehensions.
To me, the argument that string comps could be more efficient is, at
best, a weak argument. It isn't that I don't want more efficient Python
code, but adding more and more specialised, single-purpose syntactic
features for that efficiency is a poor way to do it. It makes the
language harder to learn, and more work for implementers.
But, if the efficiency gain is large, I guess it counts as an argument.
If only it were a proven optimization, not a hypothetical one.
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.)
Ultimately, I think that the three major arguments in favour are weak:
- "strings are the only (important) iterable missing a comprehension"
is just wrong;
- "str.join is unintuitive" depends on whose intuition you are talking
about, but even if we agree it is still a weak argument: programming
has many unintuitive things that need to be learned;
- and the optimization argument is purely hypothetical, and probably
not enough to justify dedicated syntax.
Another weakness is that it can only join the substrings with no
separator. I've looked at a sample of my code, and around 60% of the
time I'm joining substrings I've given a separator, e.g.
', '.join(...)
so a comprehension wouldn't work.
Ultimately I don't think this is a terrible idea, but so far it hasn't
crossed the threshhold of "benefits outweigh the costs".
--
Steve
_______________________________________________
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/LDM6DU3GSONHUZ43JLDSQRQQMWIQMGX2/
Code of Conduct: http://python.org/psf/codeofconduct/
