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