Aahz pythoncraft.com> writes:
>
> On Fri, Mar 13, 2009, Antoine Pitrou wrote:
> > R. David Murray bitdance.com> writes:
> >>
> >> You will note that what
> >> I suggested was that applications that _use the sync feature_ make
> >> it user controllable.
> >
> > I'm sorry, but if it has nothing
On Fri, Mar 13, 2009, Antoine Pitrou wrote:
> R. David Murray bitdance.com> writes:
>>
>> You will note that what
>> I suggested was that applications that _use the sync feature_ make
>> it user controllable.
>
> I'm sorry, but if it has nothing to do with Python itself, perhaps we
> could stop
On Fri, 13 Mar 2009 at 12:27, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
You will note that what
I suggested was that applications that _use the sync feature_ make
it user controllable.
I'm sorry, but if it has nothing to do with Python itself, perhaps we could stop
this sub
R. David Murray bitdance.com> writes:
>
> You will note that what
> I suggested was that applications that _use the sync feature_ make
> it user controllable.
I'm sorry, but if it has nothing to do with Python itself, perhaps we could stop
this subthread (or move it to another ML)? There are eno
On Fri, 13 Mar 2009 at 14:27, Steven D'Aprano wrote:
On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote:
On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
Seriously, though, the point is that IMO an application should not
be calling fsync unless it p
Steven D'Aprano wrote:
On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote:
On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
Seriously, though, the point is that IMO an application should not
be calling fsync unless it provides a way for that behavio
On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote:
> On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
> > R. David Murray bitdance.com> writes:
> >> Seriously, though, the point is that IMO an application should not
> >> be calling fsync unless it provides a way for that behavior to be
> >>
On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
Seriously, though, the point is that IMO an application should not be
calling fsync unless it provides a way for that behavior to be controlled
by the user.
But whether an application does it or not is
On 13Mar2009 00:35, Antoine Pitrou wrote:
| R. David Murray bitdance.com> writes:
| > Seriously, though, the point is that IMO an application should not be
| > calling fsync unless it provides a way for that behavior to be controlled
| > by the user.
|
| But whether an application does it or not
On Fri, 13 Mar 2009 11:27:54 am R. David Murray wrote:
> Seriously, though, the point is that IMO an application should not be
> calling fsync unless it provides a way for that behavior to be
> controlled by the user.
An admirable approach, but also a sweeping generalisation. Who is your
expected
R. David Murray bitdance.com> writes:
>
> Seriously, though, the point is that IMO an application should not be
> calling fsync unless it provides a way for that behavior to be controlled
> by the user.
But whether an application does it or not is none of Python's business, is it?
What is the di
On Thu, 12 Mar 2009 at 22:57, "Martin v. L?wis" wrote:
Cameron Simpson wrote:
On 12Mar2009 22:09, Martin v. L?wis wrote:
| > Let me try some examples.
| > Suppose I'm running my applications on a laptop and I don't want the
| > disk to be spinning continually while I work. I'm willing to take
On Fri, 13 Mar 2009 07:25:59 am Antoine Pitrou wrote:
> R. David Murray bitdance.com> writes:
> > By the way, I would not like to see python programmers encouraged
> > to make the same mistake that sqlite3 made. The decision about how
> > aggressive to be on flushing data to disk should be in the
On Fri, 13 Mar 2009 08:01:27 am Jim Jewett wrote:
> On 3/12/09, "Martin v. Löwis" wrote:
> >> It is starting to look as though flush (and close?) should take an
> >> optional wait parameter, to indicate how much re-assurance you're
> >> willing to wait for.
> >
> > Unfortunately, such a thing woul
On Thu, 12 Mar 2009 at 22:09, "Martin v. L?wis" wrote:
Let me try some examples.
Suppose I'm running my applications on a laptop and I don't want the
disk to be spinning continually while I work. I'm willing to take the
risk of data loss in order to extend my battery life.
So when you select
On Thu, Mar 12, 2009 at 08:25:59PM +, Antoine Pitrou wrote:
> However, I also think that any parameter to flush() or close() is a bad idea,
> since it can't be used when flushing and closing is implicit. For example when
> the file is used in a "with" statement.
I think the existing os.fsync()
On Thu, 2009-03-12 at 20:25 +, Antoine Pitrou wrote:
> I disagree. The user usually does not know which kind of flushing is needed in
> order for his data to be safe. Actually, he probably doesn't even know what
> flushing means, and that files are ever "closed".
>
> However, I also think that
Cameron Simpson wrote:
> On 12Mar2009 22:09, Martin v. L?wis wrote:
> | > Let me try some examples.
> | > Suppose I'm running my applications on a laptop and I don't want the
> | > disk to be spinning continually while I work. I'm willing to take the
> | > risk of data loss in order to extend my
Jim Jewett wrote:
On 3/12/09, "Martin v. Löwis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating s
On 12Mar2009 22:09, Martin v. L?wis wrote:
| > Let me try some examples.
| > Suppose I'm running my applications on a laptop and I don't want the
| > disk to be spinning continually while I work. I'm willing to take the
| > risk of data loss in order to extend my battery life.
|
| So when you se
On Thu, Mar 12, 2009 at 4:09 PM, "Martin v. Löwis" wrote:
> So when you select "Save" in your application, would you like the data
> to be saved, or would you accept that they get lost? If the latter,
> what kind of interaction would you perform with your application to
> indicate that you *do* wa
Jim Jewett wrote:
> On 3/12/09, "Martin v. Löwis" wrote:
>>> It is starting to look as though flush (and close?) should take an
>>> optional wait parameter, to indicate how much re-assurance you're
>>> willing to wait for.
>
>> Unfortunately, such a thing would be unimplementable on most of today
On Thu, 12 Mar 2009 at 17:01, Jim Jewett wrote:
On 3/12/09, "Martin v. L?wis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable
> Let me try some examples.
>
> Suppose I'm running my applications on a laptop and I don't want the
> disk to be spinning continually while I work. I'm willing to take the
> risk of data loss in order to extend my battery life.
So when you select "Save" in your application, would you like the d
On 3/12/09, "Martin v. Löwis" wrote:
>> It is starting to look as though flush (and close?) should take an
>> optional wait parameter, to indicate how much re-assurance you're
>> willing to wait for.
> Unfortunately, such a thing would be unimplementable on most of today's
> operating systems.
W
On Thu, 12 Mar 2009 at 20:25, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
By the way, I would not like to see python programmers encouraged to make
the same mistake that sqlite3 made. The decision about how aggressive
to be on flushing data to disk should be in the hands of th
R. David Murray bitdance.com> writes:
>
> By the way, I would not like to see python programmers encouraged to make
> the same mistake that sqlite3 made. The decision about how aggressive
> to be on flushing data to disk should be in the hands of the _user_, not
> the application.
I disagree. T
On Thu, 12 Mar 2009 at 20:56, "Martin v. L?wis" wrote:
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating syst
> It is starting to look as though flush (and close?) should take an
> optional wait parameter, to indicate how much re-assurance you're
> willing to wait for.
Unfortunately, such a thing would be unimplementable on most of today's
operating systems.
Regards,
Martin
__
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
It also looks like we can't know enough to predict all sensible
symbolic constants -- so instead use a floating point numeric value.
f.flush(wa
30 matches
Mail list logo
