On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi
<alvarezd...@gmail.com> wrote:
> This is the mindset that I had. I understand there are other ways to do what
> I am asking. (I provided one in my initial post.) I am saying it relies on
> what I believe to be a notoriously unintuitive method (str.join) and an even
> more unintuitive way of calling it ("".join).
I think this is something of an exaggeration. It's "notoriously
difficult" (;-)) for an expert to appreciate what looks difficult to a
newcomer, but I'd argue that while ''.join() is non-obvious at first,
it's something you learn once and then remember. If it's really
awkward for you, you can write `concat = ''.join` and use that (but
I'd recommend against it, as it makes getting used to the idiom
*other* people use that much harder).
> Here are 73 of them that I found by grepping through Lib.
Thank you. I only spot-checked one or two, but I assume from this list
that your argument is simply that *all* occurrences of
''.join(something) can be replaced by c"something". Which suggests a
couple of points:
* If it doesn't add anything *more* than an alternative spelling for
''.join, is it worth it?
* Is the fact that it's a quoted string construct going to add
problematic edge cases? You can't use " inside c"..." without
backslash-quoting it. That seems like it could be a problem, although
I'll admit I can't come up with an example that doesn't feel contrived
at the moment. In particular, is the fact that within c"..." you're
writing a comprehension but you're not allowed to use unescaped "
symbols, more awkward than using ''.join was originally?
> > To me, the chosen syntax is problematic. The idea of introducing
> > structural logic by using “” seems likely to cause confusion. Across all
> > languages I use, quotes are generally and almost always used to introduce
> > constant values. Sometimes, maybe, there are macro related things that may
> > use quoting, but as a developer, if I see quotes, I’m thinking: the runtime
> > will treat this as a constant.
>
> I think this is an over-simplification of the quotations syntax.
> Python has several prefix characters that you have to look out for when you
> see quotes, namely the following: r, u, f, fr, rf, b, br, rb.
> Not only can these change the construction syntax, but they can even
> construct an object of a completely different type (bytes).
On the contrary, I think you're missing the point here. When I, as a
programmer, see "..." (with any form of prefix) I think "that's a
constant". That's common for all quoting. I'd argue that even
f-strings are very careful to avoid disrupting this intuition any more
than necessary - yes, {...} within an f-string is executable code, but
the non-constant part is delimited and it's conventionally limited to
simple expressions. Conversely, it's basically impossible to view your
c-strings as "mostly a constant value".
Also, how would c-strings be handled in conjunction with other string
forms? Existing string types can be concatenated by putting them
adjacent to each other:
>>> a="hello"
>>> f"{a}, " r"world"
'hello, world'
>>>
How would c-strings work?
As code, I might want to format a generator over multiple lines. How
would c-strings work with that?
(
c"val.strip().upper() "
c"for val in file "
c"if val != '' " # Skip empty lines
c"and not val.startswith(chr(34))" # And lines commented with " -
chr(34) is ", but we can't use " directly without a backslash
)
That doesn't feel readable to me. I could use a triple-quoted
c-string, but then I have an indentation problem. Also, with triple
quoting I couldn't include those comments (or could I??? You haven't
said whether comments are valid *within* c-strings. But I assume not -
the syntax would be a nightmare otherwise).
> > Second, f-strings do not restrict the normal usage of strings for freeform
> > text content (apart from making the curly brace characters special).
>
> Not to nit-pick too much, but the following is a valid string but not a valid
> f-string.
>
> >>> s = f"This is a valid string but invalid f-string {}"
> File "<stdin>", line 1
> s = f"This is a valid string but invalid f-string {}"
> ^
> SyntaxError: f-string: empty expression not allowed
> >>>
That comes under the heading of making curly braces special...
> > 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.
>
> I view this as the strongest opposition to the idea in the whole thread, but
> I think that seal was broken with f-strings and the {}-syntax. The proposed
> syntax is different from those features only in *degree* (of deviation from
> strict char-arrays) not in *type*. But I also recognize that the delimiters
> {} go a long way in helping to mentally compartmentalize chars from python
> code.
That's a very explicit "slippery slope" argument - "now that f-strings
stopped quotes meaning constant, we can do anything we like" - and
like most such arguments, it's a massive over-generalisation.
f-strings were debated very carefully, and a lot of effort was put
into the question of whether it broke the "literal string" intuition
too much. The conclusion was that it didn't, *for that specific case*.
But there's no reason to assume that the same arguments apply for
other uses (and indeed, the decision was close enough that there's
very good reasons to assume those arguments *won't* apply in general).
> I definitely see the drawbacks of the originally-proposed syntax, but I think
> it would be beneficial to the conversation for commenters to recognize that
> python strings are not nearly as pure as some of the objections make them out
> to be. I would be happy to hear the objection that my syntax strays *too*
> far, but many of the passed-around examples attest to the fact that when
> users see quotes, they are often already in "code-evaluation" mode (eg.
> f"[{','.join('0123')}]" ).
OK. I'll object in those terms. I think your syntax proposal strays
*way* too far. And I don't believe the example you gave is a good use
of f-strings - I don't recall the context, but if it was from real
code (rather than being a constructed example to make a point) I'd
strongly insist that it be rewritten for better readability.
> I think that a comment left by steve was particularly helpful.
>
> > If we were re-doing Python from scratch, there's a good chance that we
> > would limit ourselves to a single comprehension syntax, namely generators:
> >
> >
> > list(expression for x in items if cond)
> > set(expression for x in items if cond)
> > dict((key, value) for x in items if cond)
> >
> > rather than have dedicated syntax for those three cases.
>
> Would readers see any merit in a syntax like the following?
>
> >>> dirty = "f8sjGe7"
> >>> clean = str(char for char in dirty if char in string.ascii_letters)
> >>> clean
> 'fsjGe'
>
> Or would it stray too far from the behavior of the str() constructor in
> general?
Would you object to using a different function rather than re-using
the str constructor? How about "concat"? Or maybe ''.join?
OK, so that was a little facetious, but hopefully you get my point,
that you've now reached the point where you're in effect saying that
the only thing you really want to change is the name of the ''.join
function.
> As of now, the behavior is the following.
>
> >>> dirty = "f8sjGe7"
> >>> clean = str(char for char in dirty if char in string.ascii_letters)
> >>> clean
> '<generator object <genexpr> at 0x7f10fc917660>'
And that's why reusing str isn't going to be an option. It's a
backward compatibility issue. It's not so much that anyone is relying
on str() returning that particular value, but they *do* rely on it
returning a (semi-)readable representation of the passed in value, and
not executing it if it's a generator.
> I don't intend to reinvent strings, I only mean to leverage an already
> existing means of signifying modified string construction syntax (prefixes)
> to align str construction syntax with the comprehensions available for the
> other most common builtin iterables, avoid the notoriously unintuitive
> "".join syntax, and improve readability.
The fact that you're getting responses suggesting you do want to
"reinvent strings" implies that your proposed syntax is being
understood in a way that wasn't your intent. That in itself is a
strong indicator that the syntax isn't nearly as intuitive as you'd
hoped (or as a language construct for Python typically needs to be to
fit in with Python's "easily readable" style).
> Please continue to send your thoughts! I really appreciate it!
I hope the above was of use. Overall, I'm a strong -1 on this
proposal, I'm afraid.
Paul
_______________________________________________
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/6LYPMAXHH7YVPMAD3LKMYPR6UPVWQ2U3/
Code of Conduct: http://python.org/psf/codeofconduct/
