On Sat, 2010-07-17 at 01:33 +0200, Armin Ronacher wrote: > Hi, > > On 7/17/10 1:20 AM, Chris McDonough wrote: > > Let me know if I'm missing something. > The only thing you miss is that the bytes type of Python 3 is badly > supported in the stdlib (not an issue if we reimplement everything in > our libraries, not an issue for me) and that the bytes type has no > string formattings which makes us do the encode/decode dance in our own > implementation so of the missing stdlib functions.
This is why the docs mention "bytes with benefits" instead (like the Python 2 "str" type). The existence of such a type would be the result of us lobbying for its inclusion into some future Python 3, or at least the result of lobbying for a String ABC that would allow us to define our own. But.. yeah. Stdlib support for bytes. Dunno. What I really don't want to do is implement a WSGI spec in terms of Unicodey strings just because the webby stuff in the stdlib cannot deal with bytes. Those stdlib implementations should be changed to deal with bytes-ish things instead. I actually think fixing the stdlib will end up being a driver for the "bytes with benefits" type. Supporting such a type in the implementation of stdlib functions is clearly the right way to fix it in lots of cases, because they will be able to deal with BwB and Unicodey-strings in exactly the same way. In the meantime, I think using bytes is the only sane thing to do in some interim specification, because moving from a spec which is bytes-oriented to a spec that is text-oriented now will leave us in the embarrassing position of needing to create yet another bytes-oriented spec later (as, well, I/O is bytes), when Python 3 matures and realizes it needs such a hybrid type. - C _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com