Terry Hancock <[EMAIL PROTECTED]> 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: > > "number" > | > complex > | > "real" > | > float > | > decimal > | > int > > 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 from 'baseinteger'. 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... Alex -- http://mail.python.org/mailman/listinfo/python-list
