[Python-Dev] str with base

[Thomas Wouters]

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.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!