On 10/20/2020 7:38 PM, Steven D'Aprano wrote:
On Wed, Oct 21, 2020 at 02:15:40AM +1100, Chris Angelico 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
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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KTGQLT4TY672GRF6JFV6MZHUE4J4S3NS/
Code of Conduct: http://python.org/psf/codeofconduct/
