[Python-3000] iostack, continued

[tomer filiba]

> I believe what he meant was that property change should not affect the state of
> anything but the *Python*'s object.

for reference, in sock2 i use properties to change the socket
options of sockets.

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)

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

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

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.


-tomer

On 6/7/06, Giovanni Bajo <rasky at develer.com> wrote:
> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> >> About this part: "properties raising IOError", I would like to
> >> remember that Guido pronounced on The Way properties should be used
> >> in Py3k.  Part of the pronouncement was that reading/writing
> >> properties should never have side-effects.
> >
> > That's meaningless without a definition of what counts as a
> > "side effect". Writing to a property must have *some* effect
> > on the state of something, otherwise it's pointless.
> >
> > I'm guessing he meant it shouldn't affect the state of anything
> > outside that object. But then we need to decide what counts
> > as part of the state of a file object. Does it include the
> > value of the file position of the underlying file descriptor?
> > If it does, then file.position = foo is a legitimate usage
> > of a property.
>
>
> I believe what he meant was that property change should not affect the state of
> anything but the *Python*'s object.
>
> Giovanni Bajo
>
>