Nick Coghlan ncogh...@gmail.com added the comment:
To avoid any confusion in the future, it should be noted that Antoine did not
unilaterally make the decision to commit this change to a maintenance branch.
This change was discussed on python-dev, with the ultimate decision to update
the 3.1
Pascal Chambon chambon.pas...@gmail.com added the comment:
Argh, I had indeed missed some IO-related tests, hadn't noticed the new test_io
docstring:
# Tests of io are scattered over the test suite:
# * test_bufio - tests file buffering
# * test_memoryio - tests BytesIO and StringIO
# *
Antoine Pitrou pit...@free.fr added the comment:
Your patch lacked a fix for test_largefile (I think it is skipped under
Windows). I added this and committed it in r77890. Will port to py3k.
--
resolution: - accepted
versions: -Python 2.7
___
Antoine Pitrou pit...@free.fr added the comment:
Committed in py3k (r77895, r77896) and 3.1 (r77897). Thank you Pascal!
--
resolution: accepted - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker
Pascal Chambon chambon.pas...@gmail.com added the comment:
Hello
Here is the patch for the python trunk, regarding truncate() behaviour.
I've tested it on windows and linux, against IO test suites (with -uall), in
debug and normal mode.
I've also updated some docstrings, and added tests for
Antoine Pitrou pit...@free.fr added the comment:
Thank you. The patch was committed mostly unchanged in r77802 (a few cosmetic
fixes). Now trunk and py3k must absolutely be patched in order to conform to
the new behaviour. Can you produce a patch for trunk?
--
priority: - release
Changes by Antoine Pitrou pit...@free.fr:
Removed file: http://bugs.python.org/file15931/patch26_largefile_tested.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Pascal Chambon chambon.pas...@gmail.com added the comment:
Thanks a lot B-)
I'll make a patch for trunk from now to this W.E.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Pascal Chambon chambon.pas...@gmail.com added the comment:
Hello
Just to notify that I've just tested this patch on a fresh python2.6 SVN
checkout, on Ubuntu this time (previously, it was only win32), and it passes
all IO-related tests I know.
--
Pascal Chambon chambon.pas...@gmail.com added the comment:
Allright - sorry for the failure - I've cleaned my hdd enough to launch
large_file tests too.
The thing is - are there platforms available to test a patch against the whole
test suite of python, and against several OSes ? I've found
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15909/patch26_truncate_pos_refcounts.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15765/python26_full_truncate_patch.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Pascal Chambon chambon.pas...@gmail.com added the comment:
Thanks for the detailed feedback.
According to what you said (and to details found in python docs), the current
_fileio.truncate is actually quite buggy - no reference counting ops were done
on posobj, even though it's sometimes
Antoine Pitrou pit...@free.fr added the comment:
First, I get the following compilation warnings under Linux:
/home/antoine/cpython/26/Modules/_fileio.c: In function ‘fileio_truncate’:
/home/antoine/cpython/26/Modules/_fileio.c:651: attention : unused variable
‘tempposobj’
Pascal Chambon chambon.pas...@gmail.com added the comment:
Is there anything I can do to help this patch making its way to the trunk ?
I guess it'd be better if Python2.7 benefited from it, so that users don't run
anymore the risk of relying of this undocumented and non-canonical truncate
Changes by Antoine Pitrou pit...@free.fr:
Removed file: http://bugs.python.org/file15763/Buggy patch - to be forgotten
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
___
Antoine Pitrou pit...@free.fr added the comment:
Looking at the patches:
- if you want to remove code, please remove it; don't comment it out
- please don't use C++-style comments (it will break on some compilers, produce
warnings on others)
- code lines should generally not be wider than 80
Pascal Chambon chambon.pas...@gmail.com added the comment:
Allright, I shall fix all this asap.
But it seems the C code for truncate is actually buggy in the current 2.6
_fileio.c, around line 680.
CF code below :
posobj = portable_lseek(fd, posobj, 0); - don't we lose the reference to the
Antoine Pitrou pit...@free.fr added the comment:
posobj = portable_lseek(fd, posobj, 0); - don't we lose the reference
to the old posobj there, doing a memory leak ?
It's a bit more subtle.
Here, the first reference to posobj that you get is through the
function arguments. You don't own that
Antoine Pitrou pit...@free.fr added the comment:
He, roundup ate part of the code I pasted. Here it is again:
import io
[39516 refs]
f = io.open(foo, wb, buffering=0)
[39542 refs]
f.truncate()
0L
[39544 refs]
f.truncate()
0L
[39544 refs]
f.truncate(2)
2
[39543 refs]
f.truncate(2)
2
[39542
Antoine Pitrou pit...@free.fr added the comment:
By the way, you witness the issue (less clearly though) by running the tests in
debug mode, too:
$ ./python -m test.regrtest -v test_io
test_io
test_BufferedIOBase_destructor (test.test_io.CIOTest) ... ok
test_IOBase_destructor
Pascal Chambon chambon.pas...@gmail.com added the comment:
Hi
Here is a patch for the python2.6 _fileio.c module, as well as the
corresponding testcase.
I'll check the _pyio and C _io trunk modules asap.
--
keywords: +patch
Added file:
Pascal Chambon chambon.pas...@gmail.com added the comment:
Whoups - I forgot to bugfix as well the _bytesio classes... let's just forget
about the previous patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Pascal Chambon chambon.pas...@gmail.com added the comment:
Here is the new patch for py2.6, fixing (hopefully) all the truncate() methods.
Note that the python _BytesIO implementation isn't covered by the test suite,
as it's shadowed by the C implementation ; but imo we shouldn't care : I've
Pascal Chambon chambon.pas...@gmail.com added the comment:
And here is the python trunk patch, covering _Pyio and _io modules (+
corresponding tests).
--
Added file: http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch
___
Python
Pascal Chambon chambon.pas...@gmail.com added the comment:
Hello
I'm currently finalizing the API of my raw io file implementation, but I still
have trouble with the trunk implementation of IOBase.truncate().
If I remember well, in the mailing list topic on this subject, GvR noted that
this
Antoine Pitrou pit...@free.fr added the comment:
Are there new elements, advocating a status quo on this matter ?
Nothing, it's just lacking a patch from someone interested in the
matter.
On a separate note, I'm confused about the at most phrase in the
current documentation :
---
Pascal Chambon chambon.pas...@gmail.com added the comment:
Allright, I'll try to work on it as soon as I manage to gather a decent
compilation environment on windows...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
New submission from Pascal Chambon chambon.pas...@gmail.com:
Hello
I'm having trouble around the behaviour of the io module's truncate
methods, in py3k. If I remember well, under unix and older versions of
Python (with other file types), truncate never move the fiel pointer
(and had to fake
Antoine Pitrou pit...@free.fr added the comment:
I can't tell you why it was decided to behave like this. Perhaps it was
felt that, since FileIO is low-level (lower than the file object in
2.x), it shouldn't have to remember and restore the old file position.
That argument wouldn't apply to
Pascal Chambon chambon.pas...@gmail.com added the comment:
Well, I guess it deserve discussion on the pydev mailing lits, that's
imo a rather important point, to be documented precisely.
Concerning the padding, I guess the semantic doesn't change between the
io module and the old file type, i.e
32 matches
Mail list logo
