On 12Jan2014 17:46, Brett Cannon <br...@python.org> wrote:
> THE EIBTI group are willing to support PEP 460 but beyond that don't want
> to have in Python itself anything for bytes.format() which takes in a
> string and spits out bytes. It's bytes in->bytes out and not bytes & str
> in->bytes out as the PBP group is after. The EIBTI group are arguing that
> letting str into bytes.format() and then automatically be converted to
> strict ASCII leads to conflating the text/bytes divide as well as being too
> magical, e.g. what if you actually wanted UTF-16 for you number string
> instead of ASCII; the EIBTI group **wants** to force people to make a
> decision. They are also less concerned with making users update Python 2
> code to handle this as it already needs to be updated for other Python 3
> things anyway.
[...]
I'm in the EIBTI on the whole, but I would also be happy for the
bytes.format() function to accept strings (and floats or whatever
the str.format supports) _provided_ it required an explicit encoding=
parameter to enable it.
i.e. make it easy to use, _but_ require an overt specification of
the str->bytes encoding.
You don't even need a special mode, but have it raise a ValueError
if the (default) encoding is None when an encoding became needed.
Just my 2c on Brett's EIBTI vs PBP divide. I'll try to stay off
this thread now and bikeshed only in the others...
--
Cameron Simpson <c...@zip.com.au>
You can blip it twice to clear the bore,
But blip it thrice, and you've sinned once more.
- Tom Warner <t...@dfind.demon.co.uk>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
