Nick Coghlan wrote: > Guido van Rossum wrote: > >>On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> >>>Guido van Rossum wrote: >>> >>> >>>>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. >>> >>>the same applies to hex and oct, of course. >> >>Right. And this is not a hypothetical issue either -- in Perl, hex and >>oct *do* work the other way I believe. More reasons to get rid of >>these in Python 3000. Perhaps we should also get rid of hex/oct >>lterals? > > > I'm not aware of anyone that would miss octal literals, but there are plenty > of hardware weenies like me that would find "int("DEAD", 16)" less convenient > than "0xDEAD". Python is a bit too heavyweight for a lot of embedded work, > but > its *great* for writing host-based test harnesses. > > I quite like the suggestion of using 'math.base' rather than a builtin, but > there are still issues to be figured out there: > - the math module is currently a thin wrapper around C's "math.h". Do we > really want to change that by adding more methods? > - is 'base' the right name? > - should we allow a "digits" argument, or just the radix argument? > Another possibility, since Python 3 can break backward compatibility: we could take a page out of Icon's book and use an "rN" suffix for non-decimal literals.
23 == 27r8 == 17r16 regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ _______________________________________________ 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/archive%40mail-archive.com