[Python-3000] iostack, continued

Terry Reedy tjreedy at udel.edu
Wed Jun 7 20:17:49 CEST 2006

"tomer filiba" <tomerfiliba at gmail.com> wrote in message 
news:1d85506f0606070954q50a7c7bau66fdabfe690cdb7 at mail.gmail.com...
> instead of doing
> if not s.getsockopt(SOL_SOCK, SOCK_REBINDADDR):
>    s.setsockopt(SOL_SOCK, SOCK_REBINDADDR, 1)
> you can just do
> if not s.rebind_addr:
>    s.rebind_addr = True
> which is much easier (both to maintain and read). these property-
> options also take care of platform dependent options (like the
> linger struct, which is different between winsock and bsd sockets)

Very nice.  Much more 'pythonic'.

> i can't speak for Guido now, but at first, when i proposed this
> options-via-properties mechanism, Guido was in favor. he agreed
> setsockopt is a highly non-pythonic way of doing things.
> besides, the context is different. a path object is not a stream
> object. they stand for different things. so you can't generalize
> like that -- the decision must be made on a per-case basis

I agreed with Guido's pronouncement in its context.  I also don't see it as 
applying to f.position (unless he explicitly says so).  The Python file 
object is supposed to be a fairly direct proxy for the OS'es file object.

> another key issue to consider here is convenience. it's much
> more convenient to use .position than .seek and tell. for example:

So I also like this.

> original_pos = f.position
> try:
>    ... do something with f
> except IOError:
>    f.position = original_pos
> seek and tell are much more cumbersome. they will remain there,
> of course, if only for backwards compatibility.

Tell and seek go back half a century to manipulations of serial media like 
magnetic tape;-)  For random access disks, their meaning is somewhat 
virtual or metaphorical rather than actual.  To me, its time to let go of 
them, as much as possible, and use a more modern API.

Terry Jan Reedy

More information about the Python-3000 mailing list