[Python-Dev] str with base

[Gareth McCaughan]

On Thursday 2006-01-19 11:15, Thomas Wouters wrote:
> On Thu, Jan 19, 2006 at 10:23:30AM +0000, Gareth McCaughan wrote:
...
> > 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'.

"issubclass" is horrible because wordsjammedtogetherlikethisarehardtoread,
especially when they're misleading as to pronunciation ("iss-ubclass").

Short English words are nice because they're easy to type and
(at least sometimes) their meanings are immediately obvious.
For the same reason, they're useful as variable names. Of course
the world doesn't end if a builtin name is the same as a variable
name you'd like to use, but it's ... well, "a bit disagreeable"
probably expresses about the right degree of nuisance.

> > 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.

It's not (intended as) an argument *for* any particular form.

>                                                           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.

Actually, I happen to dislike hex() slightly -- I never use or see
oct(), so don't much care about that -- for exactly that reason.

>                   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.

To me, base() is less obvious than hex(), which itself is just
ambiguous enough to cost me maybe one second per month. Not a big
deal at all, but not zero.

> 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.

You need to turn off the Python Mind Control feature. :-)

I think math.base (apart from sounding like it ought to be a
variable that controls the base in which numbers are represented,
or something of the sort) is about as much typing as to_base,
so I'm not sure how the latter can be much worse in this respect.

> > 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.

Sure, it's not disabling. But in practice it's nice to be able
to avoid builtin names, and "base" is a word I'd rather not have
to take measures to avoid: too many meanings, some of them
quite common.

(I don't care much about this, and if base() gets introduced
I shan't complain.)

-- 
g