> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4