[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
Guido van Rossum
guido at python.org
Mon May 29 21:59:32 CEST 2006
[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.
(Files don't have a writefrom() method because write() can be
polymorphic. read() can't be due to the asymmetry in the API. I guess
struct objects are different.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-checkins
mailing list