aleax at mail.comcast.net
Mon Jan 16 11:23:35 EST 2006
Terry Hancock <hancock at anansispaceworks.com> wrote:
> I'm bothered by the fact that "int" can be coerced into
> either "decimal" or "float". In practice, you should
> have to choose one or the other. Practically speaking,
Why ever?! You're indicating "is a subset of", and int IS a subset of
both (net of floats' issues with maximum sizes, of course) -- why should
you have to choose?
> it probably makes more sense to do this:
> Because, in general, it is safer (no info loss) to
> convert "int" to "decimal" where possible.
But decimal is NOTHING LIKE a subset of float; it's a SUPERSET (since 2
is a factor of 10, but not viceversa).
> I suspect this is the sort of decision that was viewed
> as "too tricky".
So _my_ preference would be to have abstract empty classes 'basenumber'
and 'baseinteger', with everything inheriting directly from 'basenumber'
except that 'int' (and if we want to keep it around 'long') inherits
The main reason for existence of baseinteger is simple: a list (or other
sequence) should accept as index any baseinteger (so a package such as
gmpy can easily have instances of gmpy.mpz "be integers", directly
acceptable as list indices, w/o having to carry around uselessly an
instance of int... inheritance from non-abstract classes is NOT just a
question of subsets and supesets, it has implications in implementation
terms, too). It's a rather specific use case, I won't cry much if
'baseinteger' goes away.
The case for 'basenumber' is much stronger, and I'm making it on
python-dev (where I already made it in the past, in the last few years);
look for [basenumber site:python.org] and you'll find the few but
informative posts that went around, mostly about 3 years ago.
My main worry is that in the quest for a "perfect hierarchy" that keeps
proving too tricky, something with real-life usefulness such as
basenumber may fall by the wayside...
More information about the Python-list