[Python-Dev] Formatting mini-language suggestion

Lie Ryan lie.1296 at gmail.com
Thu Mar 12 06:50:12 CET 2009


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 has not proven to be problem eventhough that convention is
>>> not universal.   For a thousands separator, a comma is a decent choice
>>> that makes it easy follow-on with s.replace(',', '_') or somesuch.
>>
>> In that case, I would simplify my suggestion to:
>>
>>  [[fill]align][sign][#][0][minimumwidth][,][.precision][type]
>>
>> Addition to mini language documentation:
>>  The ',' option indicates that commas should be included in the
>> output as a thousands separator. As with locales which do not use a
>> period as the decimal point, locales which use a different convention
>> for digit separation will need to use the locale module to obtain
>> appropriate formatting.
> 
> 
> This proposal has the advantage that you're not overly specifying the 
> behavior in the format string itself.
> 
> That is: the "," option is really just indicating "please insert 
> separators". With the current locale-ignorant implementation, that'd 
> just mean "a comma every 3 digits". But it leaves the door open for a 
> locale-sensitive variant of the format to be added in the future without 
> conflicting with the instructions in the format string. (as the ability 
> to specify an arbitrary character, or the ability to specify a comma 
> instead of a period for the decimal point would).
> 
> I'm not against Raymond's proposal, just against doing a *bad* job of 
> making it work in multiple locales. Locale conventions can be complex, 
> and are going to be best represented outside the format string.

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 
code that is a placeholder for whatever the locale the machine is set to.



More information about the Python-Dev mailing list