This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients davidhalter, eric.smith
Date 2018-06-03.13:54:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528034054.27.0.592728768989.issue33754@psf.upfronthosting.co.za>
In-reply-to
Content
What is the goal here? Are you just trying to simplify ast.c?

My concern is that there are many, many edge cases, and that you'll be unknowingly changing the behavior of f-strings.

One of the goals of the f-string specification is for a simple third-party parser to be able to lexically recognize f-strings just like normal, raw, or byte strings. It should require no change to such a lexer except for adding "f" where "b", "r", or "u" is currently allowed. I do not want to break that design principle. There are plenty of examples in the wild where this design was leveraged.
History
Date User Action Args
2018-06-03 13:54:14eric.smithsetrecipients: + eric.smith, davidhalter
2018-06-03 13:54:14eric.smithsetmessageid: <1528034054.27.0.592728768989.issue33754@psf.upfronthosting.co.za>
2018-06-03 13:54:14eric.smithlinkissue33754 messages
2018-06-03 13:54:14eric.smithcreate