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 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