Nick Coghlan wrote:
> With a position attribute on actual file IO objects, it should be
> possible to set it up so that the file object only invokes tell() when
> you try to *change* the position. When you simply access the attribute,
> it will return the answer from an internal variable (it ne
Giovanni Bajo wrote:
> I believe what he meant was that property change should not affect the state
> of
> anything but the *Python*'s object.
Then what counts as part of the Python object? If the
object is wrapping a C struct from some library, is it
okay for a property to change a member of th
"tomer filiba" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 m
> 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,
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> >> Here is a list of the conversion types that are currently supported by
> >> the % operator. First thing you notice is an eerie similarity between
> >> this and the documentation for 'sprintf'. :)
> >
> > Yes. This is (or was) a s
Giovanni Bajo wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>> 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 underlyin
Bill Janssen wrote:
>> Here is a list of the conversion types that are currently supported by
>> the % operator. First thing you notice is an eerie similarity between
>> this and the documentation for 'sprintf'. :)
>
> Yes. This is (or was) a significant advantage to the system. Many
> people
Talin wrote:
> I've taken your proposal as a base, and made some additional changes to
> it. In addition, I've gone ahead and implemented a prototype of the
> built-in formatter based on the revised text.
I like it!
As for somewhere to put the prototype, a patch or RFE tracker item isn't too
b
Greg Ewing <[EMAIL PROTECTED]> 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 me
