On Tue, Oct 20, 2020 at 6:20 PM Chris Angelico rosuav@gmail.com wrote:
spam = eggs = cheese = None f"{spam:d} {eggs:d} {cheese:d}" = "123 456"
Wow! That sure looks like a strong anti-pattern.
If some variable was assigned somewhere very distant in the program flow, a parser might succeed where it would otherwise fail! It's not technically spooky action at a distance, but it's troublingly close.
In contrast a plain function has none of that problem behavior.
spam, eggs, cheese = sscanf("%d %d %d", "123 432", missing=None)
I wouldn't mind a version of this that was "inspired by" f-strings. But even there, the requirements are subtly different. E.g.:
myvals = sscanf("{spam:d} {eggs:d} {cheese:d}", "123 432", missing=None)
I can see a good idea of `myvals` being a dictionary not a tuple. But that's close to the color of the bikeshed.
Just to repeat, a "scanf-string" just cannot be the same thing as an f-string. Here is a perfectly good f-string, similar to ones I use all the time:
f"More than foo is {foo+1}"
There's just no way to make f-strings into an assignment target... what is POSSIBLE is making "some subset of f-strings (yet to be precisely specified)" patterns for a scan.
I hate the idea of putting that subset to the left of an equal sign. But defining a subset as an argument for a function sounds great. Actually, however, I think the scanf-string rules should be probably not strictly a subset, but rather a "strongly overlapping set that is mostly a subset but also has a few new things."