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 paul.moore
Recipients dirn, eric.smith, gregory.p.smith, paul.moore, serhiy.storchaka, steven.daprano, xtreak
Date 2019-05-02.18:40:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1556822438.96.0.184378450414.issue36774@roundup.psfhosted.org>
In-reply-to
Content
+1 from me. It's something I'd find useful, and it's a natural extension of the f-string syntax.

> I can't decide if I'm going to allow a format specifier.

The only useful interpretation IMO would be for {expr!d:fmt} to expand to expr={expr:fmt}. If you're not willing to include that in the initial implementation, I'd rather see :fmt reserved for now, with the intention that it's implemented like this at a later date. Having :fmt apply to the whole string including the "expr=" bit would be basically useless to me. For a motivating example, consider f"{datetime.now()!d:%Y-%m-%d}", which is something I could easily imagine using.

Steven D'Aprano:
> I think there are enough use-cases for having access to
> expressions, complete with source code, as first-class
> values to make this a general feature of the language
> and not baked into f-strings. I have a proto-PEP
> discussing this.

I have no problem with something like this, but I don't think it precludes the proposed f-string extension. The use cases are sufficiently different that I'd expect the two features to live happily together - there's no need to block the f-string extension for a proposal like this.
History
Date User Action Args
2019-05-02 18:40:38paul.mooresetrecipients: + paul.moore, gregory.p.smith, eric.smith, steven.daprano, dirn, serhiy.storchaka, xtreak
2019-05-02 18:40:38paul.mooresetmessageid: <1556822438.96.0.184378450414.issue36774@roundup.psfhosted.org>
2019-05-02 18:40:38paul.moorelinkissue36774 messages
2019-05-02 18:40:38paul.moorecreate