Antoine Pitrou a écrit :
Hello,
So here is the proposed semantic, which matches established conventions:
*IOBase.truncate(n: int = None) -> int*
[...]
I still don't think there is a sufficient benefit in breaking
compatibility. If you want the file pointer to remain the same, you can
save it first and restore it afterwards manually.
Sure, but won't this truncate become some kind of a burden for py3k, if
it's twice misleading (it's not a real truncation since it can extend
the file, and it's not even a truncation or resizing in posix/win32
style, since the filepointer is moved) ?
Since it was an undocumented behaviour, and py3k doesn't seem to be
present yet in production environments (or is it ?), I'd promote this
late-but-maybe-not-too-late change.
But if the consensus prefers the current behaviour, well, it'll be OK to
me too, as long as it's sufficiently documented and advertised.
*Propositions of doc update*
Please open tracker issues for these kinds of suggestions.
Is the tracker Ok for simple suggestions too ? I thought it was rather
for obvious bugfixes, and to-be-discused propositions had better be in
mailing-lists... OK then, I'll open bugtracker issues for these. B-)
Instead of "than size", perhaps "than n".
Whoups, indeed >_<
Actually the signature would rather be:
*IOBase.truncate(size: int = None) -> int*
And I forgot to mention that truncate returns the new file size
(according to the current PEP)...
Should an exception be raised if start and/or end are out of range?
I'd advocate it yep, for the sake of "explicit errors". However, should
it be a ValueError (the ones io functions normally use) or an IndexError
(which is technically more accurate, but might confuse the user) ?
Regards,
Pascal
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
