Why no number methods?

[Alex Martelli]

"Magnus Lie Hetland" <mlh at idi.ntnu.no> wrote in message
news:9docmc$sed$1 at tyfon.itea.ntnu.no...
>
> 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

Apart from the syntax awkwardness (1. is a float...),
I don't know.  It would have some small but non-zero
usefulness to be able to pass 1.add as a bound
method rather than writing a lambda or local function.


> before Python 3000, I think it would be really cool
> if numbers got the same treatment as lists, strings,
> and dicts. (Are there any other types that don't have
> methods? OK, Null and Ellipsis don't, but that's
> different... :)

Tuples.  And the BDFL is apparently quite certain
that tuples must not have methods, as he recently
refused a patch (or PEP, I don't recall) to add the
"obvious" .count() and .index() methods to tuples.


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

That's not hard to write even today, of course.


> 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. (I mean, I can
> get quite a long way with lists and strings, but...)

You don't need to be able to write 1.add(2) to
take an OO approach.  x+y is already polymorphic
today -- x may have an __add__ method, or y a
__radd__ one.  Using a function or operator to
invoke polymorphic behavior isn't "less OO" than
using a different syntax sugar such as x.add(y):
indeed, this way you can get polymorphism on
_either_ operand (thanks to __radd__), so, it's
"twice-as-OO as x.add(y) would be":-).


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

Tuples having methods would surely not be difficult
at all to implement; I do not know the motivation
for rejecting that (not that the BDFL has to supply
one, of course:-).  If there were builtin functions
such as count(sequence, item), I would see the logic:
the function might try various possible methods on
the sequence, and finally just iterate on it and do
its own counting as a fall-back.  Most sequences
wouldn't have to implement any special "count logic",
since normal iteration logic will suffice, but some
sequences might choose to provide special code for
counting (e.g., a sequence implementing a multiset
in the obvious way might do that).  This would be
just like "item in sequence": if the sequence object
implement __contains__, it can provide special code
for faster membership-testing, else the 'in' operator
falls back to iteration over the sequence.

I don't believe it would be hard to give methods
to numbers, except for the syntax issue of accessing
the methods on numeric literals -- this might be
perhaps bypassed by declaring that 1.add(2) will
*not* be parsed correctly (it keeps being the 1.
literal followed by identifier 'add' &c -- a syntax
error) and (1).add(2) (which today raises an
AttributeError), or 1 . add(2), &c, are the ways
the attribute access is specified.  But maybe this
would raise higher squeals than today's situation:-).


But, difficulties apart, it may simply be that the
BDFL doesn't _want_ all objects to have methods --
this seems to be indicated by the tuple-methods issue.


Alex