Guido van Rossum python.org> writes:
>
> All in all I think we should change this before it's too late; it will
> affect a very small number of apps (perhaps none?), but I would rather
> have the right semantics in the future. Also, it's trivial to write
> code that doesn't care (in fact code run
On Sun, Sep 27, 2009 at 3:44 PM, Antoine Pitrou wrote:
> Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit :
> [truncate()]
>>
>> What compatibility, though?
>
> Compatibility accross the 3.x line.
Well, in this case, maybe compatibility with 2.x is more important --
this isn't somethi
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 ca
Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit :
[truncate()]
>
> What compatibility, though?
Compatibility accross the 3.x line.
> f.truncate() behaves different in 2.x than
> in 3.x, and in 2.x it seems to match the POSIX semantics (i.e. the seek
> position is unchanged even thou
On Sun, Sep 27, 2009 at 4:33 AM, Antoine Pitrou wrote:
>> 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 t
Pascal Chambon wrote:
Hello
Below is a corrected version of the PEP update, adding the start/end
indexes proposition and fixing functions signatures. Does anyone
disagree with these specifications ? Or can we consider it as a target
for the next versions of the io module ?
I would have no pro
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 i
Hello
Below is a corrected version of the PEP update, adding the start/end
indexes proposition and fixing functions signatures. Does anyone
disagree with these specifications ? Or can we consider it as a target
for the next versions of the io module ?
I would have no problem to implement this
Pascal Chambon wrote:
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
*RawIOBase*.readinto(b: bytes) -> int
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
*RawIOBase*.readinto(b: bytes) -> int
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on clarifying these impor
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon wrote:
> *RawIOBase*.readinto(b: bytes) -> int
>
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on clarifying these important corner cases is
appreciated. :-)
--
Daniel Stutzbach, Ph.D.
Hello,
> *Truncate and file pointer semantics*
[snip]
The major problem here is that you are changing the current semantics.
I don't think the argument you are making for it is strong enough to
counter-balance the backwards compatibility issue. The situation would be
different if 3.0 hadn't be
Pascal Chambon wrote:
Hello
After weighing up here and that, here is what I have come with. Comments
and issue notifications more than welcome, of course. The exception
thingy is not yet addressed.
Regards,
Pascal
*Truncate and file pointer semantics*
Rationale :
The current implementati
Hello
After weighing up here and that, here is what I have come with. Comments
and issue notifications more than welcome, of course. The exception
thingy is not yet addressed.
Regards,
Pascal
*Truncate and file pointer semantics*
Rationale :
The current implementation of truncate() always
14 matches
Mail list logo
