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
Greg Ewing wrote:
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to
deprecate it and alias it to "resize()" ? It's not very gratifying to
have duplicated methods at the beginning of a major release, but I
feel too that "truncate" is a misleading term, that h
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
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to deprecate
it and alias it to "resize()" ? It's not very gratifying to have
duplicated methods at the beginning of a major release, but I feel too
that "truncate" is a misleading term, that had better be replac
Well, system compatibility argues strongl in favor of not letting
filepointer > EOF.
However, is that really necessary to move the pointer to EOF in ANY case
? I mean, if I extend the file, or if I reduce it without going lower
than my current filepointer, I really don't expect at all the io sys
Steven D'Aprano wrote:
Using "truncate" to mean "increase in size" makes about as much sense as
having a list method called "remove" used to insert items. I can't
imagine what the committee who approved this were thinking.
I expect the reason is historical. Some time back in the
early days of
On Sat, 19 Sep 2009 06:08:23 am James Y Knight wrote:
> On Sep 18, 2009, at 3:55 PM, MRAB wrote:
> > I think that this should be an invariant:
> >
> >0 <= file pointer <= file size
> >
> > so the file pointer might sometimes have to be moved.
> >
> > As for the question of whether 'truncate' sh
Le Fri, 18 Sep 2009 21:17:29 +0200, Pascal Chambon a écrit :
Hello,
First, thanks for experimenting with this.
(as a sidenote, we lack real-world testing of non-blocking features,
perhaps you want to take a look)
> I'm currently working on a reimplementation of io.FileIO, which would
> allow
James Y Knight wrote:
On Sep 18, 2009, at 3:55 PM, MRAB wrote:
I think that this should be an invariant:
0 <= file pointer <= file size
so the file pointer might sometimes have to be moved.
As for the question of whether 'truncate' should be able to lengthen a
file, the method name sug
On Fri, Sep 18, 2009 at 2:17 PM, Pascal Chambon wrote:
> - it is unclear what truncate() methods do with the file pointer, and even
> if the current implementation simply moves it to the truncation point, it's
> very contrary to the standard way of doing under unix, where the file
> pointer is nor
On Sep 18, 2009, at 3:55 PM, MRAB wrote:
I think that this should be an invariant:
0 <= file pointer <= file size
so the file pointer might sometimes have to be moved.
As for the question of whether 'truncate' should be able to lengthen a
file, the method name suggests no; if the method
Pascal Chambon wrote:
Hello everyone
I'm currently working on a reimplementation of io.FileIO, which would
allow cross-platform file range locking and all kinds of other safety
features ; however I'm slightly stuck due to some specification
fuzziness in the IO docs.
CF http://bugs.python
[Oops! Hit Send to soon]
Pascal Chambon wrote:
Hello everyone
I'm currently working on a reimplementation of io.FileIO, which would
allow cross-platform file range locking and all kinds of other safety
features ; however I'm slightly stuck due to some specification
fuzziness in the IO docs.
Why not propose an update to the existing PEP to clarify the vaguenesses?
On Fri, Sep 18, 2009 at 12:17 PM, Pascal Chambon
wrote:
> Hello everyone
>
> I'm currently working on a reimplementation of io.FileIO, which would allow
> cross-platform file range locking and all kinds of other safety feat
26 matches
Mail list logo
