Author eric.smith
Recipients Ben.Wolfson, eric.araujo, eric.smith, mark.dickinson, petri.lehtinen, r.david.murray
Date 2011-06-03.21:56:57
SpamBayes Score 1.92048e-09
Marked as misclassified No
Message-id <1307138218.86.0.164230865457.issue12014@psf.upfronthosting.co.za>
In-reply-to
Content
The intermingling of character data and markup is far from irrelevant: that's exactly what str.format() does! I don't see how it can be irrelevant to a discussion of how the string is parsed.

Note that there are no restrictions, in general, on what's in a format specifier. Braces can be in format specifiers, if they make sense for that type. For example:

>>> from datetime import datetime
>>> format(datetime.now(), '{}%Y-%m-%d}{')
'{}2011-06-03}{'

It's definitely true that you can have valid format specifiers that cannot be represented in strings parsed by str.format(). The PEP talks about both format specifiers in the abstract (stand alone) and format specifiers contained in str.format() strings.

The current implementation of str.format() finds matched pairs of braces and call what's inside "markup", then parse that markup. This indeed restricts what's inside the markup. I believe the implementation is compliant with the PEP.

It's also true that other interpretations of the PEP are possible. I'm just not sure the benefit to be gained justifies changing all of the extant str.format() implementations, in addition to explaining the different behavior.

Many useful features for str.format() were rejected in order to keep the implementation and documentation simple.

I'm not saying change and improvement is impossible. I'm just not convinced it's worthwhile.
History
Date User Action Args
2011-06-03 21:56:58eric.smithsetrecipients: + eric.smith, mark.dickinson, eric.araujo, r.david.murray, Ben.Wolfson, petri.lehtinen
2011-06-03 21:56:58eric.smithsetmessageid: <1307138218.86.0.164230865457.issue12014@psf.upfronthosting.co.za>
2011-06-03 21:56:58eric.smithlinkissue12014 messages
2011-06-03 21:56:57eric.smithcreate