Michael Chermside wrote:
> Greg Ewing writes:
>
>> Be careful -- in Unix it's possible for different file
>> descriptors to share the same position pointer.
>
> Really? I had no idea.
>
> How does one invoke this behavior?
It happens every time you fork, and the child process
inherits copies of
Greg Ewing writes:
> Be careful -- in Unix it's possible for different file
> descriptors to share the same position pointer.
Really? I had no idea.
How does one invoke this behavior? How does current python (2.4)
behave when subjected to this?
-- Michael Chermside
__
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,
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
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
"tomer filiba" <[EMAIL PROTECTED]> wrote:
>
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
* "
Giovanni Bajo 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 defi
tomer filiba <[EMAIL PROTECTED]> wrote:
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
About thi
tomer filiba <[EMAIL PROTECTED]> wrote:
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
About thi
"tomer filiba" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> thanks for all the comments so far, they have already proved
> very helpful and furtile.
I think you meant fertile (as opposed to futile ;-)
___
Python-3000 mailing list
Py
the old thread was getting too nested, so i made a summary
of the key points raised during that discussion:
http://sebulba.wikispaces.com/project+iostack+todo
is there anything else i missed? any more comments to add
to the summary?
i'll have time to incorporate part of these issues on the weeke
14 matches
Mail list logo