[Python-Dev] basenumber redux
Raymond Hettinger
python at rcn.com
Thu Jan 19 07:55:42 CET 2006
> -----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
More information about the Python-Dev
mailing list