On Mon, Jan 6, 2014 at 8:44 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Hi,

On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner <victor.stinner@gmail.com> wrote:
>
> The PEP is a draft with open questions. First, I'm not sure that both
> bytes%args and bytes.format(args) are needed. The implementation of
> .format() is more complex, so why not only adding bytes%args?

I think we must either implement both or none of them.

Or bytes.format() only. But I do agree that only implementing the % operator is the wrong answer.

-Brett
 

> Then,
> the following points must be decided to define the complete list of
> supported features (formatters):
>
> * Format integer to hexadecimal? ``%x`` and ``%X``
> * Format integer to octal? ``%o``
> * Format integer to binary? ``{!b}``
> * Alignment?
> * Truncating? Truncate or raise an error?

Not desirable IMHO. bytes formatting should serve mainly for templating
situations (i.e. catenate and insert bytestrings into one another). We
cannot start giving text-like semantics to bytes objects without
confusing non-experts.

> * format keywords? ``b'{arg}'.format(arg=5)``
> * ``str % dict`` ? ``b'%(arg)s' % {'arg': 5)``

Yes, bytes formatting must support the same calling conventions as str
formatting.

BTW, there's a subtlety here: ``%s`` currently means "insert the result
of calling __str__", but bytes formatting should *not* call __str__.

> * Floating point number?
> * ``%i``, ``%u`` and ``%d`` formats for integer numbers?
> * Signed number? ``%+i`` and ``%-i``

No, IMHO.

Regards

Antoine.