Mark Dickinson <dicki...@gmail.com> added the comment:

Thanks for the doc suggestions.

Actually, the current docs were revised recently;  this issue is a helpful 
reminder to me that those doc revisions need to be backported. :)  If you want 
to see the current docs, look at:

http://docs.python.org/dev/library/struct.html

I'm +0 on adding the standard sizes to the table of format codes.

I also agree it might make sense to swap the 'Format Character' section and the 
'Byte Order, Size and Alignment' section.

That's all for now;  I'll look at this properly sometime soon.

The standard/native terminology is fairly ingrained;  I'm not sure whether it's 
really worth changing it, but we can look at the explanations and make sure 
that they're clear.

> Programming skills and platform knowledge at C level should not be a 
> requirement to understand and use struct, so perhaps the references to > C 
> should be less high-profile,

Agreed, though I think the references to C should certainly be there, since 
they will help some users, and since part of the struct module's raison d'etre 
is to allow communication with data written/read by C programs.

The note about ILqQ returning Python longs might be better omitted;  the 
difference between int and long should be irrelevant to most users.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to