On Wed, Oct 21, 2020 at 6:06 AM David Mertz <me...@gnosis.cx> wrote:
>
> On Tue, Oct 20, 2020 at 8:41 PM Chris Angelico <ros...@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
_______________________________________________
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/NEDDUXO5M3ECRIHSYXEQ3FFHNMPNWE3Z/
Code of Conduct: http://python.org/psf/codeofconduct/
