[Eric S. Raymond]
> Is the right answer to add the convert-to-base slot and deprecate the
> other two?
That would fix "the other" lump here in Python, that e.g.
>>> int("111", 3)
13
>>>
has no inverse. string->int is happy with any base in 2..36 inclusive, but
int->string is spelled via 3 different builtins covering only 3 of those
bases.
It would be more *expedient* to add "just" a __bin__/nb_bin method + a way
to spell binary int literals + a %b format + a bin() builtin.
On the fifth hand, I doubt anyone would want to add new % format codes for
bases {2..36} - {2, 8, 10, 16}.
So it will remain lumpy no matter what. I look forward to the PEP <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4