James Harris wrote:
On 24 Aug, 02:19, Max Erickson <maxerick...@gmail.com> wrote:
It can be assumed however that .9. isn't in binary?
That's a neat idea. But an even simpler scheme might be:
.octal.100
.decimal.100
.hex.100
.binary.100
.trinary.100
until it gets to this anyway:
.thiryseximal.100
At some point, abandoning direct support for literals and just
having a function that can handle different bases starts to make a
lot of sense to me:
int('100', 8)
64
int('100', 10)
100
int('100', 16)
256
int('100', 2)
4
int('100', 3)
9
int('100', 36)
1296
This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.
Why would a programmer be expecting an arbitrary-radix numeric literal
typed in by a user or read from a file? If you're reading it from a
file, you've already got it in some satisfactory form, binary or
otherwise. If you're taking it as input from a user, they're not going
to know the Python syntax anyway, and would type in the radix and then
the literal (in the unlikely case this would ever be required, which is
still hard to imagine).
Either way, conversion is, as Max showed, one line of code. It's hard
to see the explicit need for truly arbitrary-radix literals in any
language -- and I'm the guy who's put quaternary literals in syntaxes
he's had to develop just for fun. Binary, octal, decimal, hexadecimal,
sure. Beyond that it's a solution begging for problems.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
Do not seek death. Death will find you.
-- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list
