[Python-ideas] Different bases format specification
Nick Coghlan
ncoghlan at gmail.com
Sat Dec 3 02:31:37 CET 2011
More information about the Python-ideas mailing list
Sat Dec 3 02:31:37 CET 2011
- Previous message: [Python-ideas] Different bases format specification
- Next message: [Python-ideas] Different bases format specification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Dec 3, 2011 at 10:12 AM, T.B. <bauertomer at gmail.com> wrote: > I suggest using the precision field in the format specification for integers > for that. Supporting arbitrary bases for string formatting has been discussed and rejected in the past (both in the context of PEP 3101's introduction of new string formatting and on other occasions). Nobody has ever produced convincing use cases for natively supporting formatting with bases other than binary, octal, decimal and hexadecimal. Accordingly, those 4 are supported explicitly via the 'b', 'o', 'd' and 'x'/'X' formatting codes, while other formats still require an explicit conversion function. As for "Why Not?" 1. 'd' stands for decimal. If support for arbitrary bases were added, it would need to be as a separate format code (e.g. 'i' for integer) 2. The explicit 'b', 'o' and 'x' codes are related to integer literal notation (0b10, 0o777, 0x1F), not to the second argument to int() 3. The use cases just aren't that strong. When you start dealing with base36 and base64, you're not talking about formatting numbers for human readers any more, you're talking about encoding numbers as short pieces of text. Better to let people decide exactly the behaviour they want by coding it themselves. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-ideas] Different bases format specification
- Next message: [Python-ideas] Different bases format specification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list