On 5/29/06, Guido van Rossum <guido at python.org> wrote: > [python-checkins] > > >> * Added socket.recv_buf() and socket.recvfrom_buf() methods, that > > >> use the buffer > > >> protocol (send and sendto already did). > > >> > > >> * Added struct.pack_to(), that is the corresponding buffer > > >> compatible method to > > >> unpack_from(). > > [Guido] > > > Hm... The file object has a similar method readinto(). Perhaps the > > > methods introduced here could follow that lead instead of using two > > > different new naming conventions? > > On 5/27/06, Bob Ippolito <bob at redivi.com> wrote: > > (speaking specifically about struct and not socket) > > > > pack_to and unpack_from are named as such because they work with objects > > that support the buffer API (not file-like-objects). I couldn't find any > > existing convention for objects that manipulate buffers in such a way. > > Actually, <fileobject>.readinto(<bufferobject>) is the convention I > started long ago (at the time the buffer was introduced. > > > If there is an existing convention then I'd be happy to rename these. > > > > "readinto" seems to imply that some kind of position is being > > incremented. > > No -- it's like read() but instead of returning a new object it reads > "into" an object you pass. > > > Grammatically it only works if it's implemented on all buffer > > objects, but > > in this case it's implemented on the Struct type. > > It looks like <structobject>.pack_to(<bufferobject>, <other args>) is > similar to <fileobject>.readinto(<bufferobject>) in that the buffer > object receives the result of packing / reading. So I assume you're suggesting the following renames: pack_to -> packinto recv_buf -> recvinto recvfrom_buf -> recvfrominto (I don't like that last one very much. I'll go ahead and make those renames once I return.)
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