On Wed, Oct 21, 2020 at 5:07 AM David Mertz <mertz@gnosis.cx> wrote:
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.
Not sure what you mean. It either succeeds or fails based on the string it's given, but if it succeeds, it assigns only those that match. So if you want some or all of them to have default values, you assign them beforehand. It's only necessary if (a) you expect to have optional matches, and (b) you need a non-matching variable to have a value. If you want a variable to have a value, you assign it. It's that simple.
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.
Yes, but ONLY if we get dictionary unpacking. Otherwise, what's the point of any of this?
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.
*sigh* Scanning and printing are not the same. This has been repeated many times, yet STILL people object on the basis that they won't be the same. You can do this: x = [a + 1, b + 1] But you can't do this: [a + 1, b + 1] = x Does that mean that multiple assignment is broken? ChrisA