[Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c (original) (raw)

Martin Blais blais at furius.ca
Wed May 31 12:35:39 CEST 2006

On 5/29/06, Guido van Rossum <guido at python.org> wrote:

[python-checkins] > >> * Added socket.recvbuf() and socket.recvfrombuf() methods, that > >> use the buffer > >> protocol (send and sendto already did). > >> > >> * Added struct.packto(), that is the corresponding buffer > >> compatible method to > >> unpackfrom().

[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) > > packto and unpackfrom 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, .readinto() 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 .packto(, ) is similar to .readinto() 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.)

More information about the Python-Dev mailing list