[Lie Ryan]
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 customs from all over the world). Then have a special country
James Y Knight wrote:
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point has not proven to be pr
On Wed, Mar 11, 2009 at 8:34 PM, Raymond Hettinger wrote:
>> I expect that nobody likes that idea,
>
> Do you mean the idea of a thousands separator
> or the idea of also parameterizing the decimal point
> or both?
Sorry, neither. I meant the idea of having to write a PEP. :-)
(Added back pytho
[Guido van Rossum]
I suggest moving this to python-ideas and
writing a proper PEP.
Okay, it's moved.
Will write up a PEP, do research on what other languages
do and collect everyone's ideas on what to put in the shed.
(hundreds and ten thousands grouping, various choices of
decimal points
Raymond Hettinger wrote:
>
> [James Y Knight]
>> 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-
2009/3/11 Tennessee Leeuwenburg :
> Is there a general strategy used in Python development which I should be
> aware of? i.e. is it customary to type-check every argument of an interface
> method? Or is it customary not to perform type checking up-front and simply
> allow the exception to occur dee
Hi all,
I am currently looking at issue 5236. This issue regards the exception
raised when a bytes string is passed into time.strptime. In addition to the
specific question I have regarding this issue, I wasn't sure if this was
something for python-dev or for the issue comment. However, it does co
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? ;)
No, but they need to provide the full file API. If we add a sync()
method to file objects, that becomes part of the "
On Wed, Mar 11, 2009 at 6:01 PM, Antoine Pitrou wrote:
> Raymond Hettinger rcn.com> writes:
>>
>> Financial users in particular find the locale approach to be frustrating and
> non-obvious. Putting in a
>> thousands separator is a
>> common task for output destined to be read by non-programmers.
James Y Knight writes:
> 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? :)
Likewise, China
[James Y Knight]
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? :)
It is not the goal to
Would there be interest in a filetools module? Replies and
discussion to python-ideas please.
I've been using and maintaining a few filesystem hacks for, let's
see, almost nine years now:
http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/fileutil.py
(The first version of that was pro
Nick Coghlan gmail.com> writes:
>
> The tempfile module would be another example.
Do you really need your temporary files to survive system crashes? ;)
> For that reason, I think Steven's idea of a filetools module which
> provided context managers and the like that wrapped *existing* file-like
On Mar 11, 2009, at 9:06 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
The current formatting mini-language provisions left/right/center
alignment, prefixes for 0b 0x 0o, and rules on when to show the
plus-sign. I think it would be far more useful to provision a simple
way of specifying a
Raymond Hettinger wrote:
> The current formatting mini-language provisions left/right/center
> alignment, prefixes for 0b 0x 0o, and rules on when to show the
> plus-sign. I think it would be far more useful to provision a simple
> way of specifying a thousands separator.
>
> Financial users in p
Raymond Hettinger rcn.com> writes:
>
> Financial users in particular find the locale approach to be frustrating and
non-obvious. Putting in a
> thousands separator is a
> common task for output destined to be read by non-programmers.
Please note that for it to be useful in all parts of the wor
Greg Ewing wrote:
> Antoine Pitrou wrote:
>
>> What do you mean? open() doesn't allow you to wrap other file objects.
>
> I'm talking about things like GzipFile that take a
> filename and mode, open the file and then wrap the
> file object.
The tempfile module would be another example.
For that
The current formatting mini-language provisions left/right/center alignment, prefixes for 0b 0x 0o, and rules on when to show the
plus-sign. I think it would be far more useful to provision a simple way of specifying a thousands separator.
Financial users in particular find the locale approach
Antoine Pitrou wrote:
What do you mean? open() doesn't allow you to wrap other file objects.
I'm talking about things like GzipFile that take a
filename and mode, open the file and then wrap the
file object.
--
Greg
___
Python-Dev mailing list
Pytho
Greg Ewing canterbury.ac.nz> writes:
>
> I like this, because it doesn't expand the signature that
> file-like objects need to support. If you're wrapping
> another file object you just need to pass on the mode
> string and it will all work.
What do you mean? open() doesn't allow you to wrap oth
2009/3/11 Greg Ewing :
> Lie Ryan wrote:
>
>> I actually prefer strings. Just like 'w' or 'r' in open().
>>
>> Or why not add "f" "c" as modes?
>>
>> open('file.txt', 'wf')
>
> I like this, because it doesn't expand the signature that
> file-like objects need to support. If you're wrapping
> anothe
Martin v. Löwis wrote:
That should be implement by passing O_SYNC on open, rather than
explicitly calling fsync.
On platforms which have it (MacOSX doesn't seem to,
according to the man page).
This is another good reason to put these things in the
mode string.
--
Greg
___
Lie Ryan wrote:
I actually prefer strings. Just like 'w' or 'r' in open().
Or why not add "f" "c" as modes?
open('file.txt', 'wf')
I like this, because it doesn't expand the signature that
file-like objects need to support. If you're wrapping
another file object you just need to pass on the
On Wed, Mar 11, 2009 at 7:37 PM, Raymond Hettinger wrote:
> [Christian Heimes]
I'm +1 for a simple (!) test discovery system. I'm emphasizing on simple
because there are enough frameworks for elaborate unit testing.
>
> Test discovery is not the interesting part of the problem.
Int
On Thu, 12 Mar 2009 01:21:25 am Antoine Pitrou wrote:
> Christian Heimes cheimes.de> writes:
> > In my initial proposal one and a half hour earlier I suggested
> > 'sync()' as the name of the method and 'synced' as the name of the
> > flag that forces a fsync() call during the close operation.
>
>
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 properly, it's up to the app to call fsy
Barry Warsaw wrote:
Of course, a careful *nix application can ensure that the file owners
and mod bits are set the way it needs them to be set. A convenience
function might be useful though.
A specialised function would also provide a place for
dealing with platform-specific extensions, su
Antoine Pitrou:
> It depends on what you call "ACLs". It does copy the chmod permission bits.
Access Control Lists are fine grained permissions. Perhaps you
want to allow Sam to read a file and for Ted to both read and write
it. These permissions should not need to be reset every time you
mod
On Wed, Mar 11, 2009 at 13:20, Benjamin Peterson wrote:
> 2009/3/11 Eric Smith :
> > I'm implementing support for auto-numbering of str.format() fields (see
> > http://bugs.python.org/issue5237). I'm reasonably sure that when I'm
> done
> > modifying the C implementation I'll need to change the si
2009/3/11 Eric Smith :
> I'm implementing support for auto-numbering of str.format() fields (see
> http://bugs.python.org/issue5237). I'm reasonably sure that when I'm done
> modifying the C implementation I'll need to change the signatures of
> string.Formatter._vformat, str._formatter_parser, and
I'm implementing support for auto-numbering of str.format() fields (see
http://bugs.python.org/issue5237). I'm reasonably sure that when I'm
done modifying the C implementation I'll need to change the signatures
of string.Formatter._vformat, str._formatter_parser, and/or
str._formatter_field_na
> Maybe it would make more sense for "synced" to force fsync() on each
> flush, not only on close. I'm not sure how useful it is, but that's
> what "synced" would imply to me.
That should be implement by passing O_SYNC on open, rather than
explicitly calling fsync.
Regards,
Martin
__
> This is especially true given Windows has recently introduced a
> transactional API for NTFS. Although the tone is - err - gushing - it
> (a) should give some information on what is available, and (b) was high
> on my google search list
>
> http://msdn.microsoft.com/en-us/magazine/cc163388.asp
Antoine Pitrou wrote:
Eric Smith trueblade.com> writes:
Why wouldn't sync just be an optional argument to close(), at least for
the "sync_on_close" case?
It wouldn't work with the "with" statement.
Well, that is a good reason, then!
___
Python-De
Scott Dial wrote:
Aahz wrote:
On Wed, Mar 11, 2009, Antoine Pitrou wrote:
After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
open(..., sync_on="close")
open(..., sync_on="flush")
with a default of None meaning no implicit syncs.
That looks good, though I'd prefe
Eric Smith trueblade.com> writes:
>
> Why wouldn't sync just be an optional argument to close(), at least for
> the "sync_on_close" case?
It wouldn't work with the "with" statement.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Antoine Pitrou wrote:
I think your "synced" flag is too vague. Some applications may need the file to
be synced on close(), but some others may need it to be synced at regular
intervals, or after each write(), etc.
Why wouldn't sync just be an optional argument to close(), at least for
the "sy
On Wed, Mar 11, 2009, Scott Dial wrote:
> Aahz wrote:
>> On Wed, Mar 11, 2009, Antoine Pitrou wrote:
>>> After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
>>>open(..., sync_on="close")
>>>open(..., sync_on="flush")
>>>
>>> with a default of None meaning no implicit
Aahz wrote:
> On Wed, Mar 11, 2009, Antoine Pitrou wrote:
>> After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
>>open(..., sync_on="close")
>>open(..., sync_on="flush")
>>
>> with a default of None meaning no implicit syncs.
>
> That looks good, though I'd prefer
On Wed, Mar 11, 2009, Antoine Pitrou wrote:
>
> After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
>open(..., sync_on="close")
>open(..., sync_on="flush")
>
> with a default of None meaning no implicit syncs.
That looks good, though I'd prefer using named constant
Christian Heimes cheimes.de> writes:
>
> And sync_on="flush" implies sync_on="close"?
close() implies flush(), so by construction yes.
> Your suggestion sounds like
> the right way to me!
I'm glad I brought something constructive to the discussion :-))
___
Antoine Pitrou schrieb:
> After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
>open(..., sync_on="close")
>open(..., sync_on="flush")
>
> with a default of None meaning no implicit syncs.
And sync_on="flush" implies sync_on="close"? Your suggestion sounds like
the
After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
open(..., sync_on="close")
open(..., sync_on="flush")
with a default of None meaning no implicit syncs.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.o
Christian Heimes cheimes.de> writes:
>
> In my initial proposal one and a half hour earlier I suggested 'sync()'
> as the name of the method and 'synced' as the name of the flag that
> forces a fsync() call during the close operation.
I think your "synced" flag is too vague. Some applications ma
Christian Heimes wrote:
Guido van Rossum wrote:
Let's not think too Unix-specific. If we add such an API it should do
something on Windows too -- the app shouldn't have to test for the
presence of the API. (And thus the API probably shouldn't be called
fsync.)
In my initial proposal one and a
Guido van Rossum wrote:
> Let's not think too Unix-specific. If we add such an API it should do
> something on Windows too -- the app shouldn't have to test for the
> presence of the API. (And thus the API probably shouldn't be called
> fsync.)
In my initial proposal one and a half hour earlier I
Oleg Broytmann phd.pp.ru> writes:
>
>That's easy to fix - only copy ownership if the effective user id == 0.
But errors should not pass silently. If the user intended the function to copy
ownership information and the function fails to do so, it should raise an
exception.
Having implicit sp
On 11/03/2009 1:55 PM, Guido van Rossum wrote:
On Tue, Mar 10, 2009 at 7:45 PM, Christian Heimes wrote:
Antoine Pitrou wrote:
Christian Heimes cheimes.de> writes:
...
Let's not think too Unix-specific. If we add such an API it should do
something on Windows too -- the app shouldn't have to
On Wed, Mar 11, 2009 at 11:56:13AM +, Antoine Pitrou wrote:
> Oleg Broytmann phd.pp.ru> writes:
> >Only root can change file ownership - and yes, there are scripts that
> > run with root privileges, so why not copy?
>
> Because the new function would then be useless for non-root scripts
Oleg Broytmann phd.pp.ru> writes:
>
>Only root can change file ownership - and yes, there are scripts that
> run with root privileges, so why not copy?
Because the new function would then be useless for non-root scripts, and
encouraging people to run their scripts as root would be rather bad
Christian Heimes cheimes.de> writes:
>
> It's more than an object oriented convenience. fsync() takes a file
> descriptor as argument. Therefore I assume fsync() only syncs the data
> to disk that was written to the file descriptor.
Ok, I agree that a .sync() method makes sense.
__
On Wed, Mar 11, 2009 at 11:43:33AM +, Antoine Pitrou wrote:
> As for owner and group, I think there is a very good reason that it doesn't
> copy
> them: under Linux, only root can change these properties.
Only root can change file ownership - and yes, there are scripts that
run with root p
Neil Hodgson gmail.com> writes:
>
>shutil.copystat does not copy over the owner, group or ACLs.
It depends on what you call "ACLs". It does copy the chmod permission bits.
As for owner and group, I think there is a very good reason that it doesn't copy
them: under Linux, only root can change
Joachim König wrote:
To me, the flaw seem to be in the close() call (of the operating
system). I'd expect the data to be
in a persistent state once the close() returns.
I wouldn't, because that would mean that every cp -r would effectively
do an fsync() for each individual file it copies, whi
Antoine Pitrou:
> How about shutil.copystat()?
shutil.copystat does not copy over the owner, group or ACLs.
Modeling a copymetadata method on copystat would provide an easy to
understand API and should be implementable on Windows and POSIX.
Reading the OS X documentation shows a set of low
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 properly, it's up to the app to call fsync(),
and it's only necessary when you're doing on
>> We already have os.fsync() and os.fdatasync(). Should the sync() (and
>> datasync()?) method be added as an object-oriented convenience?
>
> It's more than an object oriented convenience. fsync() takes a file
> descriptor as argument. Therefore I assume fsync() only syncs the data
> to disk tha
A.M. Kuchling wrote:
With zipfile, you could at least access the .fp attribute
to sync it (though is the .fp documented as part of the interface?).
For this one, I'd like to add the sync as a method (so that Zip-inside-
Zip is eventually possible). In fact, a sync on an exposed writable
59 matches
Mail list logo