Author eric.smith
Recipients arjennienhuis, benjamin.peterson, christian.heimes, eric.smith, exarkun, ezio.melotti, flox, glyph, gvanrossum, loewis, martin.panter, pitrou, serhiy.storchaka, terry.reedy, uau, vstinner
Date 2013-01-23.23:55:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
So it sounds like the use case is (as Glyph said in msg180432):

- Provide a transition for users of 2.7's of str %-formatting into a style that's compatible with both str in 2.7 and bytes in 3.4.

In that case the only options I see are to implement __mod__ or .format for bytes in 3.4. I'd of course prefer to use .format, although __mod__ would probably make the transition easier (no need to move to .format first). It would probably also make the implementation easier, since there's so much less code in str.__mod__. But let's assume we're using .format [1].

Given the restricted use case, and assuming we using .format, the implementation would not need to support:
- Types other than bytes, int, float.
- Subclasses of these types with custom formatting.
- !s, !r, or !a (none of the ! conversions). [2]

But it would support all of the specifiers for formatting strs (except now for bytes), floats, and ints.

I haven't looked through the str.format or {str,int,float}.__format__ code since the PEP 393 work, so I'm not really sure if we could stringlib-ify the code again, or if it would just be easier to reimplement it as separate bytes-only code.

[1] It's open for debate whether .format or .__mod__ is preferable.
[2] Since %-formatting supports %r and %s, this point is arguable.
Date User Action Args
2013-01-23 23:55:20eric.smithsetrecipients: + eric.smith, gvanrossum, loewis, terry.reedy, exarkun, pitrou, vstinner, christian.heimes, benjamin.peterson, glyph, ezio.melotti, arjennienhuis, flox, uau, martin.panter, serhiy.storchaka
2013-01-23 23:55:19eric.smithsetmessageid: <>
2013-01-23 23:55:19eric.smithlinkissue3982 messages
2013-01-23 23:55:19eric.smithcreate