[Python-Dev] Fuzziness in io module specs - PEP update proposition V2

[Pascal Chambon]

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090928/026d23a8/attachment-0001.htm>