On Wed, Oct 21, 2020 at 6:06 AM David Mertz <mertz@gnosis.cx> wrote:
On Tue, Oct 20, 2020 at 8:41 PM Chris Angelico <rosuav@gmail.com> wrote:
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.
So in your idea, after the above line runs, `cheese` will remain undefined?! That's a different anti-pattern than the one I thought, but equally bad.
Notice that is a HUGE asymmetry with regular unpacking. I can never run:
a, b, c = some_expression
And wind up with a and b defined, but silently continue the program with c undefined.
In your idea, is it the case that a line like yours above can simply NEVER fail, in the sense of raising exceptions? So maybe it runs and nothing is actually bound?! I hate that even more than what I previously thought the idea was.
No; it can fail if the pattern actually rejects it. For instance, a pattern of "a{x}b{y}c" can match the string "a" but won't assign to y, however it can't match the string "q" because that doesn't match. This behaviour of leaving variables unassigned happens ONLY if there's a partial match. And just like with a regex, it would be easy enough to have a notation that demands end-of-string, and cannot match unless you reach that point in the pattern right as you reach the end of the string.
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.
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.
Well, "formatting" more generally, not only printing. But the fact they are different is EXACTLY the point I have tried to make a number of times. Trying to shoe-horn a "formatting string" into a role of a "scanning string" is exactly the problem. They are NOT the same.
I said "print" because the comparison is between printf and scanf, but yes, formatting generally (sprintf isn't really "printing", but then again, Python's print function can print to anything too, and the pprint module has formatting functions that don't print).
As I say, developing a "scanning mini-language" that is *inspired by* the formatting language sounds great. Trying to make the actual f-string do double-duty as a scanning mini-language is a terrible idea. That way lies Perl.
Well... yes. And oddly enough, developing a scanning mini-language inspired by the formatting language is *exactly* what this proposal is, and has always been.
It really does! Imagine trying to explain "What is an f-string?" in Python 3.11 under the proposal (I'm not sure which version is actually proposed, but under any of them). The answer becomes "Depending on context, the meaning and interpretation of the symbols is one of these several things." For the most part, Python tries hard to avoid "context sensitive grammar." (Yes, I know exceptions, modulo is definitely different from string interpolation, for example... although grammatically it's actually not, just an operator that does very different things with strings versus numbers).
What is a comma? Please explain that to me with fewer convolutions than this. What is an assignment target? Are all of these the same? TARGET = thing TARGET += thing with thing as TARGET: for TARGET in thing: except ThingException as TARGET: import thing as TARGET Python already has many contexts in which something is slightly different. An f-string being assigned to isn't the same as an f-string being constructed. They are related, but distinct. In real, practical terms, what will happen is that the vast majority of pattern strings can be used identically on the RHS and LHS, and if you parse a string using a particular pattern and then format it back, it'll give back the same thing you started with. But that's not a guarantee, it can never be guaranteed, and we wouldn't want it to be that restricted anyway. ChrisA