On Sun, Sep 20, 2020 at 03:59:40AM +0100, Rob Cliffe via Python-ideas wrote:
> -1 on the whole proposal.
I agree with the negative on this proposal. I don't think that f-strings
are a good fit for this, and I'm not sure that we need syntax for
something that could be handled by a function almost as well.
But having said that, I'm going to play Devil's Advocate:
> Whereas this proposal
> - Is a really *obscure* and *non-obvious* way of assigning to
> variables. I doubt that anybody could readily guess the meaning when
> seeing it for the first time.
For the first time? Maybe not. But the first time I saw Python code, I
couldn't make heads or tails of it. All those mysterious square brackets
and colons:
for x in items[1:]:
obj[x] = something
I had no idea what it was, had never even heard of the term "slicing",
let alone what it did. Some things you just have to learn.
> - Would add to the interpreter the bloat of a whole parsing engine
> whose working would be a *totally **obscure* "black box" (and I suspect
> would be hard to implement correctly the first time).
I suspect it won't be that hard really. It's a simple form of pattern
matching, simpler than regular expressions. In fact you can build a
scanf-type function from regular expressions, and back in Python 2.5
days that used to be part of the documentation.
https://docs.python.org/2.5/lib/node49.html
With a little bit of work, you could make something that took a target
string with scanf-style tokens, turn it into a regex, and parse a
string. That would let you write something like:
path, errors, warnings = scanf('%s - %d errors, %d warnings', line)
I'd use something like that.
The only advantage, I guess, of f-string like syntax is that the
variable names can be embedded inside the template string:
f"{path:s} - {errors:d} errors, {%warnings:d}" = line
but I'm not convinced that's actually an advantage. I think I prefer the
C-style for this.
> - Would require a lot of work to implement and maintain (including
> maintaining the docs)
I don't think that implementation is that hard, although I'm not
volunteering to do the work :-)
And maintanence would be relativly little unless new functionality is
added.
> a feature which might not be used much. (IMO no
> convincing use cases have been presented so far. No doubt there are
> some. Just IMO not enough to justify the proposal.)
Do you think that there are no use-cases for scanf and sscanf in C? How
about regexes? Pattern matching? This is just a variant of those.
> Even providing
> reasonably helpful error messages could be quite a lot of work (a
> blanket ValueError, e.g., would move it towards the "unusable" end of
> the spectrum).
I'm not sure what the errors would be, but they surely wouldn't be more
cryptic than what you get with a regex, namely silent failure :-)
> - Is subject to greedy/non-greedy parsing *ambiguities*. Whatever
> the choice(s) made, the results will be surprising to some of the people
> some of the time. And trying to resolve them would surely slow down the
> parsing process.
scanf if not intended as a full-blown parser. It is an intentionally
simple parser, to solve simple problems.
> - The behaviour of said "black box" parsing engine _/could not be
> changed in any way/_ by users if it wasn't exactly what they wanted,
> which I suspect would happen quite often, and not just because of the
> greedy/non-greedy issue.
Just because a built-in solution exists, doesn't mean people can't write
their own. If someone needs something that isn't handled by the
scanf-style parser, they can always write their own regex, or their own
parser.
Sometimes we want a 500 gigawatt nuclear fusion reaction; but sometimes
we just want a AA battery. This is the AA battery of parsing.
Personally, I think people use more AA batteries than 500GW fusion
reactors :-)
> - As others have mentioned: could inject variables into locals()
> making debugging harder.
I'm dubious about that too. I think it would be better to keep the
parsing separate from the name binding, and use regular assignment for
that.
> In short, "assigning" to f-strings is not and cannot be a simple
> reversal of having them in expressions. Rather, it is opening a big
> can of worms.
My feeling is that f-strings is the wrong solution to this problem. It
strikes me as a case of "when all you have is a hammer":
"f-strings are great! Let's use f-strings for scanning strings!"
Yeah, f-strings might be great, but I don't think they are a good match
for this functionality.
But I would definitely use the functionality.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/GMV5BYRIUSOHJN7JKA4SAOBN6PBMCTPU/
Code of Conduct: http://python.org/psf/codeofconduct/
