[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5 (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Mon Jan 6 14:44:52 CET 2014
- Previous message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Next message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100 Victor Stinner <victor.stinner at 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.
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.
- Previous message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Next message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]