On 02.10.2015 16:26, Eric V. Smith wrote:
bf'{foo}'
Might succeed or fail, depending on what foo returns for __format__. If foo is 'bar', it succeeds. If it's '\u1234', it fails.
I know a lot of functions that fail when passing the wrong kind of arguments. What's so wrong with it?
But some of the other arguments are making me think bf'' is a bad idea, so now I'm leaning towards not implementing it.
I see. Do you think of an alternative solution? I was digging deeper into the matter of binary/byte strings formatting in order to sympathise why {} is not usable for binary protocols. Let's look at this practical example https://blog.tox.chat/2015/09/fuzzing-the-new-groupchats/ I hope the tox protocol fully qualifies as a wireframe protocol. What he's trying to do it is to fuzzing his new groupchat implementation by creating more-or-less random packages and feed them into tox core to see if it breaks. He conveniently uses this type of syntax to describe the structure of the first header: Header 1: [ Packet ID (1 b) | Chat ID hash (4 b) | Sender PK (32 b) | nonce (24 b) ] Interested in writing a fuzzer, I would find the following really helpful as it mirrors the description within his blog post: header1 = bf'{packet_id}{chat_id}{sender_pk}{nonce}' # which should be the same as header1 = b'%b%b%b%b' % (packet_id, chat_id, sender_pk, nonce) I wouldn't mind specifying the encoding for all non-byte-string arguments. Why? Because I would be working with bytes anyway, so no formatting (as in format()) would be necessary in the first place. However, I like the syntax for specifying the structure of (byte) strings. Does this makes sense? Best, Sven