> > 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. -Travis _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com