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