On Tue, Mar 10, 2009 at 2:11 PM, Christian Heimes wrote:
> Multiple blogs and news sites are swamped with a discussion about ext4
> and KDE 4.0. Theodore Ts'o - the developer of ext4 - explains the issue
> at
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54.
>
>
> Pyt
[new name instead of "wait" -- but certainty is too long, patience too
hard to spell, etc...]
>> class file(_file): ...
>> def flush(self, sure=0):
> super().flush(self)
> if sure < 0.25:
> return
> if sure < 0.5 and os.fdatasync:
> os.fdatasync(
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 Thu, Mar 12, 2009 at 18:22, Tennessee Leeuwenburg wrote:
> Hi all,
>
> I am continuing to look at issues in the issue tracker. It would be handy
> to be able to update some of the metadata fields. For contributions, it's
> fine to just be able to upload patches / post messages, but I can see a
Tennessee Leeuwenburg wrote:
> I am continuing to look at issues in the issue tracker. It would be handy to
> be able to update some of the metadata fields. For contributions, it's fine
> to just be able to upload patches / post messages, but I can see any number
> of issues which could use a bit o
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
Hi all,
I am continuing to look at issues in the issue tracker. It would be handy to
be able to update some of the metadata fields. For contributions, it's fine
to just be able to upload patches / post messages, but I can see any number
of issues which could use a bit of looking after.
e.g. http:
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
Newsflash!
A large number of Pythoneers has signed up already, for this reason
alone it is worth booking!
If you already know you are joining the conference, why not save some
money in these financially uncertain times and take advantage of the
extra early bird rate!
The extra early bird rate is
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()
Martin v. Löwis wrote:
>> auto-delete is one of the nice features of tempfile. Another feature
>> which is entirely appropriate to this usage, though, though, is creation
>> of a non-conflicting filename.
>
> Ok. In that use case, however, it is completely irrelevant whether the
> tempfile module
Tim Golden wrote:
> Martin v. Löwis wrote:
>>> Can I ask which flavour of Sphinx is being used to build the py3k docs?
>>
>> The proper procedure to build the documentation is
>>
>> make update
>> make htmlhelp #say
>
>
> I think you misunderstood my question. I can build the docs
> for 2.x, say
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
> auto-delete is one of the nice features of tempfile. Another feature
> which is entirely appropriate to this usage, though, though, is creation
> of a non-conflicting filename.
Ok. In that use case, however, it is completely irrelevant whether the
tempfile module calls fsync. After it has gener
Martin v. Löwis wrote:
Can I ask which flavour of Sphinx is being used to build the py3k docs?
The proper procedure to build the documentation is
make update
make htmlhelp #say
I think you misunderstood my question. I can build the docs
for 2.x, say -- have done so, in fact many times.
I w
Martin v. Löwis wrote:
The sync is necessary to ensure that the data is written to the disk
before the old file overwrites the new filename.
>>> You still wouldn't use the tempfile module in that case. Instead, you
>>> would create a regular file, with the name base on the name of the
>>>
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
>>> The sync is necessary to ensure that the data is written to the disk
>>> before the old file overwrites the new filename.
>> You still wouldn't use the tempfile module in that case. Instead, you
>> would create a regular file, with the name base on the name of the
>> important file.
>>
> Uhm...
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
Martin v. Löwis wrote:
>> Something that doesn't require deterministicly named tempfiles was Ted
>> T'so's explanation linked to earlier.
>>
>> read data from important file
>> modify data
>> create tempfile
>> write data to tempfile
>> *sync tempfile to disk*
>> mv tempfile to filename of importan
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
James Y Knight wrote:
You might be interested to know that in India, the commas don't come
every 3 digits. In india, they come every two digits, after the first
three. Thus one billion = 1,00,00,00,000. How are you gonna represent
*that* in a formatting mini-language? :)
We outsource it.
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
Nick Coghlan wrote:
[[fill]align][sign][#][0][minimumwidth][,sep][.precision][type]
'sep' is the new field that defines the thousands separator.
Wouldn't it be better to use a locale setting for this,
instead of having to specify it in every format string?
If an app is using a particular th
> 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
> Can I ask which flavour of Sphinx is being used to build the py3k docs?
The proper procedure to build the documentation is
make update
make htmlhelp #say
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
> Something that doesn't require deterministicly named tempfiles was Ted
> T'so's explanation linked to earlier.
>
> read data from important file
> modify data
> create tempfile
> write data to tempfile
> *sync tempfile to disk*
> mv tempfile to filename of important file
>
> The sync is necessa
Raymond Hettinger wrote:
Eric Smith pointed-out that these are already
handled by the "n" specifier in the locale module (albiet only
for integers).
It's supported by float, but it's just not very useful. For Decimal it's
unsupported. Maybe this isn't a distinction worth pointing out.
Proposa
Tim Golden wrote:
> Tim Golden wrote:
>> Can I ask which flavour of Sphinx is being used to build the py3k docs?
>> I've taken the naive approach of simply pulling the sources from
>> branches/py3k and then calling make checkout to fetch the appropriate
>> sources, but these are from http://svn.pyt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Bazaar users!
There's a new Bazaar plugin you can use to more easily access read-
only or read-write branches on code.python.org. This plugin provides
the 'py:' url prefix. For example, to get the trunk branch with the
plugin installed,
Fixed typo in the example with spaces and commas.
Discussion draft at: http://www.python.org/dev/peps/pep-0378/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
andrew cooke wrote:
Tim Golden wrote:
Tim Golden wrote:
Can I ask which flavour of Sphinx is being used to build the py3k docs?
I've taken the naive approach of simply pulling the sources from
branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http
Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
>> It depends on what you mean by "temporary".
>>
>> Applications like OpenOffice can sometimes recover from an application
>> crash or even a systems crash and give you the opportunity to restore
>> the temporary files that were lef
Tim Golden wrote:
Can I ask which flavour of Sphinx is being used to build the py3k docs?
I've taken the naive approach of simply pulling the sources from
branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http://svn.python.org/projects and are
the
Steven D'Aprano pearwood.info> writes:
>
> It depends on what you mean by "temporary".
>
> Applications like OpenOffice can sometimes recover from an application
> crash or even a systems crash and give you the opportunity to restore
> the temporary files that were left lying around.
For such
On Thu, 12 Mar 2009 01:03:13 pm Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
> > The tempfile module would be another example.
>
> Do you really need your temporary files to survive system crashes? ;)
It depends on what you mean by "temporary".
Applications like OpenOffice can sometim
Can I ask which flavour of Sphinx is being used to build the py3k docs?
I've taken the naive approach of simply pulling the sources from
branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http://svn.python.org/projects and are
the same for 2.x and 3.
Here's an update incorporating all the comments received so far.
* Put into PEP format
* Fixed typos
* The suggestion for modifying the locale module was dropped.
* The "n" specifier in the local module was referenced
* Fixed minimumwidth --> width
* PERIOD --> DOT
* Added suggestions by Lie Ryan
Nick Coghlan gmail.com> writes:
>
> On the performance side... the overhead from fsync() itself is going to
> dwarf the CPU overhead of going through a wrapper class.
The significant overhead is not in calling sync() or flush() or close(), but in
calling methods which are supposed to be fast (re
On Mar 11, 2009, at 22:43 , Cameron Simpson wrote:
On 11Mar2009 10:09, Joachim K?nig wrote:
Guido van Rossum wrote:
On Tue, Mar 10, 2009 at 1:11 PM, Christian Heimes
wrote:
[...]
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54
.
[...]
If I understand the post
-On [20090312 06:50], Lie Ryan (lie.1...@gmail.com) wrote:
>How about having a country code field, e.g. en-us would format according
>to US locale, in to India, ch to China, etc... that way the format
>string would become very simple (although the lib maintainer would need
>to know
55 matches
Mail list logo