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
to get a string representing 123 in base 5, or
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.
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.)