Home Original page

[Python-Dev] PEP 460 reboot

Glenn Linderman v+python at g.nevcal.com
Tue Jan 14 23:02:58 CET 2014 
On 1/14/2014 4:46 AM, Nick Coghlan wrote:
> The one remaining way I could potentially see a formatb method working
> is along the lines of what Glenn (I think) suggested: just like struct
> definitions, the formatb specifier would have to consist*solely*  of
> substitution fields. However, that's getting awfully close to being
> just an alternate spelling for the struct module or bytes.join at that
> point, which hardly makes for a compelling case to add two new methods
> to a builtin type.

Yes, after someone drew the parallel between my "format specifier only" 
pedantry, and struct.pack (which I hadn't used), I agree that they are 
almost just different spellings for the same things.

The two differences I could see is that struct.pack doesn't support 
variable length items, and struct.pack doesn't support "interpolation", 
which is the whole beauty of the % type syntax... the ability to have a 
template, and interpolate values.

My pedantry DID allow for template work, but they had to be specified in 
HEX the way I specified it yesterday.

Let me repeat that syntax:

b"%{hex-codes}v"

That was mostly so the format string could be ASCII, yet represent any 
byte. That is somewhat clunky, when actually wanting to represent 
characters.  At the next level of abstraction, one could define a 
"format builder" that would take Unicode specifications, and "compile" 
them into the binary interpolation strings, but if doing that, you could 
just as well compile them into functions using struct.pack formats, with 
the parameters interspersed with the "template" data, except for 
struct.pack's inability to deal with variable length data.

So struct is attempting to emulate C structs, and variable length data 
is extremely awkward in C structs also, so I guess it provides a good 
emulation :)

So if I were to look for features to add to Python3 to support template 
interpolation for users of non-ASCII encodings, which could, of course, 
also be used by users of ASCII-based encodings, I guess I would recommend:

1) extend struct to handle variable length data items
2) provide a sample format compiler function that would translate a 
Unicode format description into a function that would use struct.pack, 
and pre-encode (according to the format specification) the template 
parts into parameters for struct.pack).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140114/6d7f501c/attachment.html>
More information about the Python-Dev mailing list