On Jan 22, 2013, at 11:39 AM, Antoine Pitrou <report@bugs.python.org> wrote:

> Antoine Pitrou added the comment:
> 
> I agree with the idea that the feature set should very limited, actually perhaps more limited than what you just said. For example, I think any kind of implicit str->bytes conversion is a no-no (including the "r" and "a" format codes).

Twisted doesn't particularly need str->bytes conversion in this step, implicit or otherwise, so I have no problem with leaving that out.

> Still, IMO even a simple feature set warrants a PEP, because we want to devise something that's generally useful, not just something which makes porting easier for Twisted.

Would it really be so bad to add features that would make porting Twisted easier?  Even if you want porting Twisted to be as hard as possible, there are plenty of other Python applications that don't use Twisted which nevertheless need to emit formatted sequences of bytes.  Twisted itself is a good proxy for this class of application; I really don't think that this is overly specific.

> I also kind of expect Twisted to have worked around the issue before 3.4 is out, anyway.

The problem is impossible to work around in the general case.  While we can come up with clever workarounds for things internal to buffering implementations or our own protocols, Twisted exposes an API that allows third parties to write protocol implementations, which quite a few people do.  Every one of those implementations (and every one of Twisted's internal implementations, none of which are ported yet, just the core) faces a series of frustrating implementation choices where the "old" style of b'x' % y or b'x'.format(y) resulted in readable, efficient value interpolation into protocol messages, but the "new" style of b''.join([b'x1', y_to_bytes(y), b'x2']) requires custom functions, inefficient copying, redundant bytes<->text transcoding, and harder-to-read protocol framing literals.  This interacts even more poorly with oddities like bytes(int) returning zeroes now, so there's not even a reasonable 2<->3 compatible way of, say, setting an HTTP content-length header; b'Content-length: {}\r\n'.format(length) is now b''.join([b'Content-length: ', (bytes if bytes is str else str)(length).encode('ascii'), b'\r\n']).

This has negative readability, performance, and convenience implications for the code running on both 2.x and 3.x and it would be really nice to see fixed.  Honestly, it would still be a porting burden to have to use .format(); if you were going to do something _specifically_ to help Twisted, the thing to do would be to make both .format and .__mod__ work; most of our protocol code currently uses % to do its formatting.  However, upgrading to a "modern" API is not an insurmountable burden for Twisted, and I can understand the desire to trade off that work for the simplicity of having less code to maintain in Python core (and less to write for this feature), as long as the "modern" API is actually functional enough to make very common operations close to equivalently convenient.