[Python-Dev] basenumber redux

[Raymond Hettinger]

> -----Original Message-----
> From: python-dev-bounces+python=rcn.com at python.org [mailto:python-dev-
> bounces+python=rcn.com at python.org] On Behalf Of Martin v. Löwis
> Sent: Wednesday, January 18, 2006 3:36 PM
> To: Jason Orendorff
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] basenumber redux
> 
> Jason Orendorff wrote:
> > Really this is just further proof that type-checking is a royal pain
> > in Python.  Or rather, it's not hard to cover the builtin and stdlib
> > types, but it's hard to support "duck typing" too.  Are we going
about
> > this the right way?
> 
> It's not as bad. There is nothing wrong with restricting the set of
> acceptable types if callers would have no problems to convert their
> input into one of the acceptable types.

Somehow my earlier post on this thread didn't seem to take.

There are problems for callers converting their inputs:

* currently existing number-like objects would need be retro-fitted with
a new base class and possibly change their behavior from old-style to
new-style.

* some useful classes (such as a symbolic type) already inherit from
str.  That prevents them from also being able to inherit from
basenumber.

I'm -1 on the proposal because the benefits are dubious (at best it
simplifies just a handful of code fragments); it adds yet another API to
learn and remember; it is darned inconvenient for existing code seeking
to emulate number-like behavior; and it precludes number emulation for
classes that already have a built-in base class.

For the most part, functions that enforce type checking are up to no
good and make life harder for their callers.  If Python ultimately grows
interfaces, I hope they remain optional; as soon as functions start
insisting on interface checking, then it will spread like cancer.  The
basenumber proposal is essentially a step down that slippery slope.


Raymond


Raymond