I will doggedly keep posting to this thread rather than creating more threads.
In another thread, Nick has said he's okay with my proposal (not sure
if that includes %s or not, but it now seems of lesser importance) as
long as we simultaneously introduce formatb() and formatb_map() (the
latter is just a minor variation of the former, so I won't mention it
further).
But formatb() feels absurd to me. PEP 460 has neither a precise
specification or any actual examples, so I can't tell whether the
intention is that the format string can *only* contain {...} sequences
or whether it can also contain "regular" characters. Translating to
formatb(), my question comes down to the legality of the following
example:
b'Hello, {}'.formatb(name) # Where name is some bytes object
If this is allowed, it reintroduces the ASCII bias (since the
substring 'Hello' is clearly ASCII).
If this isn't allowed, it feels like a perversion of the notion of a
"formatting language", and I really don't see the attraction over
using a combination of concatenation and the struct module, perhaps
augmented with some use of bytes([i]) as an alternative to %c or {!c}
(if that is what is meant by PEP 460 with 'c modifier' -- I can't find
the word 'modifier' in the docs for format().
Note that I honestly don't understand which of these PEP 460 means.
Either way, PEP 460's motivation seems kind of subjective and esthetic:
"""
While there are reasonably efficient ways to accumulate binary data
(such as using a bytearray object, the bytes.join method or even
io.BytesIO), none of them leads to the kind of readable and intuitive
code that is produced by a %-formatted or {}-formatted template and a
formatting operation.
"""
I would buy this if a binary format string could contain embedded text
(like 'Hello' in my example above), but then the argument about
avoiding ASCII bias seems to fall apart so I am at a loss about what
Nick actually wants, and even about what PEP 460 actually specifies.
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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
