Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:39 AM, Antoine Pitrou <[email protected]> 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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue3982>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
