On Thu, Jan 19, 2006 at 10:23:30AM +0000, Gareth McCaughan wrote:
+1 on introducing base()
Introducing a new builtin with a name that's a common, short English word is a bit disagreeable.
While I don't particularly mind the new function in either the builtin module or another, like math, I don't understand the problem with the name. Most builtin names are short and english-ish words. I like that, I'm glad they are that way, and the two names I dislike most are 'isinstance' and 'issubclass'.
The other thing about the name "base" is that it's not entirely obvious which way it converts: do you say
base(123,5)to get a string representing 123 in base 5, or
base("123",5)to get the integer whose base 5 representation is "123"?
This is an argument for 'str(123, 5)', but I don't agree. Not _everything_ has to be obvious at first glance. The very same could be said about hex(), oct(), dir(), even names like list() (what does it list?), str() (stripping something?), etc. Having int() do it one way and base() the other makes fine sense to me, and I don't see it as any harder to explain than, say, why hex("123") doesn't return 291. I've personally never had to explain hex/oct's behaviour.
While I think 'str' would be a slightly better name than 'base' (despite the specialcasing of numbers,) I don't mind either. I do mind names like 'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on autocompletion in my editor.
Alternatively, a name like "to_base" that clarifies the intent and is less likely to clash with variable names might be an improvement.
Builtins aren't reserved names, so the clash is minimal.