Why no number methods?

[Michael Hudson]

On Mon, 14 May 2001, Magnus Lie Hetland wrote:

> OK, so I've had a look at Ruby. I liked some things and disliked
> others... But it made me wonder, why can't we have methods such as
> 1.add(2) etc. in Python?

Nit-picky reason:  Tricky for the lexer, as "1." is a floating point
literal.  You'd have to type (1).add, probably.

Real reason:  there isn't one, really.  But I think it used to be a
general principle that immutable types in Python didn't have methods (or
any attributes at all, in fact) - cf. len(x) vs. x.len().  This changed
with 1.6 and string methods.

> I must admit I haven't looked to hard at the source code of the
> interpreter, so I'm approaching this from a bit of a naïve angle...
> But if arithmetic etc. will call suitable methods when objects are
> involved, why can't method calls be converted to arithmetic when
> numbers are involved?

As said above, no real reason.  It's not obvious to me that it buys one
much though (this could be because strings have more in the way of
internal structure than floats or ints - if you know the value of a
number, that's about all you need, whereas it's reasonable to ask a string
"how many 'e's are there in you".  Just waffling, but there have been
times I'd have liked a .bitlength() method on longs).

> And while I know we probably can't expect full object-orientedness
> before Python 3000, I think it would be really cool if numbers got the
> same treatment as lists, strings, and dicts.

If 2.2 == 3000 (I don't think fp arithmetic is *that* inaccurate <wink>)
you *may* get your wish.  Check out (in more sense than one) what Guido's
been doing on the descr-branch in CVS recently.

> (Are there any other types that don't have methods? OK, Null and
> Ellipsis don't, but that's different... :)

tuples.

(also: frame objects, code objects, type objects, functions, method
objects, ... but these all have attributes if not methods).

> And perhaps there could be a UserNumber (possibly with integer and
> float subclasses or something) class, like UserList etc?

One of the implications of the descr-branch is that it becomes possible to
subclass built-in types.  (Which I would like: the ability to have custom
behaviour on insertion into a list without taking a performance whack for
getting items out again appeals to me).

> The main reason for these musings is that I was considering an
> object-oriented approach to teaching basic Python, but it seems a bit
> awkward to have to avoid numbers and arithmetic.

A foolish consistency is the hobgoblin of little minds?  It has to be
said, I don't conceive of the operation

1 + 2

as passing a message "__add__" to the integer object "1".  But I concede
that it's a valid viewpoint, and an area where Python is somewhat
inconsistent today.

> (I mean, I can get quite a long way with lists and strings, but...)

Bah, all you need is lambda & Church numerals <wink>.

> Well, well. Anyone care to explain why this is difficult or horribly
> difficult to implement?

Did you read my last python-dev summary?

> Wishing-for-some-consistency-but-not-holding-my-breath'ly yours,

I wouldn't.

Cheers,
M.