Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)

Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

Logged In: YES 
user_id=849994

I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?

Logged In: YES 
user_id=1364480

This issue is on windows XP.
Wasnt tested on other versions (only 2.5b1 and b2)

I expect the code to always write at the end according to
the documentation. However if I user file seek (opend as A+)
to read from begining of the file, the write also goes to
begining of file.

Note - in the code snippet, please remove the last
f.seek(0,2) to see the problem! (it should have been in a
comment)

Logged In: YES 
user_id=849994

Perhaps you can try in on Windows, Tim...

Can anyone confirm this for Windows and 2.6? Closing otherwise.

I can't reproduce it with python2.6 on Vista. The newer C runtime 
(msvcr90.dll) probably corrected this.