On 10/20/2020 7:38 PM, Steven D'Aprano wrote:
or even:
f"{acc},{date},{type},{amount:[0-9.]} {description},{refnum:12s}{reference}" = line At the point you have something that complicated, I think that existing solutions with regexes or parsers is better. Overloading something that looks like an f-string with a mini-language that is way more complicated
On Wed, Oct 21, 2020 at 02:15:40AM +1100, Chris Angelico wrote: than the mini-language used in actual f-strings is, I think, a losing proposition.
I'm completely opposed to this feature, but let me make a few comments here. Not only is the mini-language here more complicated, it's the exact antithesis of __format__ machinery. With __format__, the logic is "I've got an object, which obviously has a known type, ask it how to format itself with a format spec I haven't even looked at". With the discussion I've seen so far with f-string assignment targets, you're saying "I see a format spec, let me deeply inspect the format spec, guess the type of the object it might apply to, then I'll guess on how to go from a string to that type of object". In the example above, what's the type of "amount" after it's created? A str? An int? Double? Complex? Datetime?
- 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. Not sure what the concern with "inject[ing] variables" is. What you see as a feature, some of us see as a problem: the fact that *some* variables will be updated even if the pattern doesn't match.
So if you have a pattern that doesn't match the given string, it could still have side-effects of creating or over-writing local variables.
The f-string has to be a literal - it's not a magic object that you can assign to and new locals appear.
f-strings have str.format to work around the literal vs. computed value problem. They use the identical format specs, because as I noted above, the machinery doesn't try and understand the format spec. Only the object itself (well, its type) interprets them, via __format__. What's the fallback equivalent in the f-string as assignment target case? I think you should provide similar functionality using non-literals. If not the magic "locals pop into existence" version, then at least the same parsing ability. That is, you should be able to say: s = "{acc},{date},{type},{amount:[0-9.]} {description},{refnum:12s}{reference}" acc, date, type, amount, description, refnum, reference = super_scanf(s) You'd also need this to allow for i18n, just as i18n can't use f-strings. I'd be opposed to adding something like this without being able to also operate on non-literals. So first we should spec out how my super_scanf function would work, and how it would figure out the values (and especially their types) to return. I think this is the weakest, most hand-wavy part of any proposal being discussed here, and it needs to be solved as a prerequisite for the version that creates locals. And the beauty is that it could be written today, in pure Python. Eric