[issue36798] f-strings do not support top-level :=

[Guido van Rossum]

Guido van Rossum  added the comment:

PEP and docs have been amended.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset ae2c32f32b61f3b141ba4b0b1ad71781d2f9a1a1 by Guido van Rossum 
(Logan Jones) in branch 'master':
bpo-36798: Updating f-string docs for := use case (GH-13107)
https://github.com/python/cpython/commit/ae2c32f32b61f3b141ba4b0b1ad71781d2f9a1a1


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Logan Jones]

Change by Logan Jones :


--
keywords: +patch
pull_requests: +13021
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Logan Jones]

Logan Jones  added the comment:

I'm going to try to tackle this. I'm not exactly sure how to go about updating 
the PEP, but the docs should have a PR in the next 15 minutes or so.

--
nosy: +Logan Jones

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Eric V. Smith]

Eric V. Smith  added the comment:

I agree with Serhiy about the need to update PEP 572 to mention this.

--
keywords: +easy
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

And I think that PEP 572 should be updated too. This is a corner case that was 
omitted at initial consideration of the PEP.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Eric V. Smith]

Eric V. Smith  added the comment:

Because of the backward compatibility issues, I'm not going to change the 
f-string parser for this. We'll just need to document the requirements for 
using parens if you want to use :=. This is similar to the existing 
documentation about lambdas and f-strings in 
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals

Patches welcome!

To be clear: like lambdas, this is just limitation of embedding expressions 
inside strings, and it's also a limitation because format specs can start with 
equal signs. It's not a restriction because I think f-strings shouldn't contain 
"top-level" := expressions.

--
assignee: eric.smith -> 
components: +Documentation -Interpreter Core
priority: release blocker -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Stefan Behnel]

Stefan Behnel  added the comment:

FWIW, I think it's equally reasonable to allow assignment expressions directly 
in f-strings, as it is to require parentheses with a reference to the 
invalidity of top-level expressions.

That makes me lean towards adding a parse-time error message that suggests the 
right way to do it, and leave it out as a feature for now, because it risks 
conflicting with ":" as format separator. We do not know yet if we will really 
need this feature. It's easier to add the feature later, than to remove it 
again in case we find that it gets in the way more than it helps.

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Emily Morehouse]

Emily Morehouse  added the comment:

Ah yes, that's what I meant. I was thinking about the confusion between 
f-strings (evaluated immediately and stored as a string) vs other versions of 
string formatting which are evaluated when used. I've seen the mix of the two 
confuse people when evaluating performance. I don't think this is particularly 
relevant to this issue though, so we can ignore it :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

f-strings are defined and used at the same place, as any other expression. You 
can not save an f-string to a variable, as you can not save a multiplication. 
But you can save a string which is a result of the f-string evaluation.

Perhaps you were fooled by the name of f-strings. It looks as a special kind of 
strings, but actually it is a kind of expressions, like addition or 
multiplication.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Emily Morehouse]

Emily Morehouse  added the comment:

My initial reaction is that named expressions should not be valid in f-strings 
and should instead raise an exception, the same way that using `a := 10` does.

>>> a := 10
  File "", line 1
a := 10
  ^
SyntaxError: invalid syntax

It could be expected that named expressions could be used in f-strings in the 
same way as, say, list comprehensions or when used in parenthesis. One of the 
tricky things about named expressions is that the scope of the variable being 
assigned to gets "elevated" to the enclosing scope (this is a slightly 
simplified explanation but applies for most cases).

Since f-strings are executed when defined and not where they are used, this 
could lead to confusing behavior. Is it available only when defined? Would 
users expect a variable to be available again when the f-string if it were 
saved to a variable? Would we modify the expected behavior of named expressions 
to contain scope to only the f-string? I'm not sure that any of these are 
particularly clear in behavior or in the definitions laid out in PEP 572.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36798] f-strings do not support top-level :=

[Eric V. Smith]

Change by Eric V. Smith :


--
title: := breaks f-strings -> f-strings do not support top-level :=

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com