Perhaps the most relevant thing to pull from this conversation is back to what Martin has asked about before: "flexible array members". A TCP packet has no defined length (there isn't even a header field in the packet for this, so in fairness we can talk about IP packets which do). There is no way for me to describe this with the pre-PEP data-formats.
I feel like it is misleading of you to say "it's up to the package to do manipulations," because you glanced over the fact that you can't even describe this type of data. ISTM, that you're only interested in describing repetitious fixed-structure arrays.
Yes, that's right. I'm only interested in describing binary data with a fixed length. Others can help push it farther than that (if they even care).
If we are going to have a "default Python way to handle data-formats", then don't you feel like this falls short of the mark?
Not for me. We can fix what needs fixing, but not if we can't get out of the gate.
I fear that you speak about this in too grandiose terms and are now trapped by people asking, "well, can I do this?" I think for a lot of folks the answer is: "nope." With respect to the network packets, this PEP doesn't do anything to fix the communication barrier.
Yes it could if you were interested in pushing it there. No, I didn't solve that particular problem with the PEP (because I can only solve the problems I'm aware of), but I do think the problem could be solved. We have far too many nay-sayers on this list, I think.
Right now, I don't have time to push this further. My real interest is the extended buffer protocol. I want something that works for that. When I do have time again to discuss it again, I might come back and push some more.
But, not now.