On 1/18/06, Alex Martelli email@example.com wrote:
On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote:
On 1/18/06, Raymond Hettinger firstname.lastname@example.org wrote:
I'd propose bin() to stay in line with the short abbreviated names.
There has been some previous discussion about removing hex()/oct()
builtins for Python 3.0, IIRC. I sure don't think bin() belongs
Perhaps introduce a single function, base(val, radix=10, prefix=''), as a universal base converter that could replace bin(), hex(), oct(), etc.
That would give us fewer builtins and provide an inverse for all the int() conversions (i.e. arbitrary bases). Also, it would allow an unprefixed output which is what I usually need.
+1. Differs from Neal's format() function by not magically determining the prefix from the radix which I like.
I'm not sure I see the advantage of, say,
print base(x, radix=2, prefix='0b')
print '0b'+base(x, radix=2)
IOW, if the prefix needs to be explicitly specified anyway, what's the advantage of specifying it as an argument to base, rather than just string-concatenating it?
It collects the data that is expected to be used in the common case in a single location/operation. This would allow you to do something like ``base(x, **radix_and_prefix_dict)`` and have everythihng in a nice, neat package.
Plus the operation would be faster if base() is written in C. =)
The other option is to go with Neal's solution for automatically including the prefix for known prefix types, but instead of it being a boolean, let it be a string argument. That means if you want no prefix you would just set the argument to the empty string. Not setting it will just use the most sensible prefix or none if one is not known for the specified radix. Could have something somewhere, like string or math, where more radix/prefix pairs can be added by the user and have base() reference that for its prefix values.
IOW I am +0 on prefix in one of these forms.