[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

[Martin Blais]

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.)