I'm not sure I believe this should be a builtin. I think the
threshold for new builtins ought to be nearly as high as the threshold
for new keywords. Or the proposer ought to make an argument about
what the function should not go in a module.
On 1/19/06, Guido van Rossum
On 1/18/06, Raymond Hettinger
Guido, we may be converging on a consensus for my proposal:
So far no one has shot at it, and it has gathered +1's from Steven, Alex, Brett, and Nick.
I think we ought to let this sit for a while and come back to it in a few week's time. Is 'base' really the right name? It could just as well be considered a conversion in the other direction. In common usage, 'base' and 'radix' are about synonymous (except no-one uses radix). Pethaps the 2nd argument should not be a keyword argument?
Also, this discussion made me wonder if conversions using other bases than 10 should even be built-ins. A library module seems a more appropriate place. The prevalence here of people who actually use hex numbers on a regular basis is probably easily explained by a combination of old-timers, language implementers, and super-geeks; hardly the typical Python user. The desire of (bright) beginners to do any kind of non-decimal conversion probably stems from a misguided meme (dating back to the invention of computers) that in order to learn about computers you ought to begin by learning about Boolean algebra and binary numbers. That might be true long ago, but today, binary, octal and hexadecimal numbers are mostly a curiosity used in obscure low-level APIs like ioctl().
To keep it simple, the proposal is for the value to be any int or long. With an underlying __base__ method call, it wouldn't be hard for someone to build it out to support other numeric types if the need arises.
Let's not. What would 3.14 be expressed in base 3?
The output would have no prefixes. As Alex pointed out, it is easier and more direct to add those after the fact if needed.
Care to pronounce on it?
Rather not yet.
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu