Alex Martelli wrote: >> As I suggested in a different message: Why are you doing that >> in the first place? > > > Because isinstance is faster and handier than testing with try/except > around (say) "x+0".
Nit: I think you should not test. Instead, you should starting you mean to do if the test passes, and then expect TypeErrors from doing so. > As to why I want to distinguish numbers from non-numbers, let me quote > from a message I sent in 2003 (one of the few you'll find by searching > for [basestring site:python.org] as I have repeatedly recommended, but > apparently there's no way to avoid just massively copying and pasting...): As I said in that other message, I found this one, and still don't understand what the use case is, because the example you give still reads hypothetical (I'm sure there is an actual example behind it, but you don't say what that is). > """ > def __mul__(self, other): > if isinstance(other, self.KnownNumberTypes): > return self.__class__([ x*other for x in self.items ]) > else: > # etc etc, various other multiplication cases So what *are* the "various other multiplication cases"? You just shouldn't be doing that: multiplication shouldn't mean "item multiplication" sometimes, and various other things if it can't mean item multiplication. > in Python/bltinmodule.c , function builtin_sum uses C-coded typechecking > to single out strings as an error case: > > /* reject string values for 'start' parameter */ > if (PyObject_TypeCheck(result, &PyBaseString_Type)) { > PyErr_SetString(PyExc_TypeError, > "sum() can't sum strings [use ''.join(seq) instea This is indeed confusing: why is it again that sum refuses to sum up strings? > [etc]. Now, what builtin_sum really "wants" to do is to accept numbers, > only -- it's _documented_ as being meant for "numbers": it uses +, NOT > +=, so its performance on sequences, matrix and array-ish things, etc, > is not going to be good. But -- it can't easily _test_ whether something > "is a number". If we had a PyBaseNumber_Type to use here, it would > be smooth, easy, and fast to check for it. There shouldn't be a check at all. It should just start doing the summing, and it will "work" if PyNumber_Add works for the individual items. Of course, there is an education value of ruling out string addition, since there is a better way to do that, and there should be only one obvious way. I see nothing wrong in summing up sequences, matrices, and arrayish things, using sum. > A fast rational number type, see http://gmpy.sourceforge.net for > details (gmpy wraps LGPL'd library GMP, and gets a lot of speed and > functionality thereby). Ok, so mpq are rational numbers. >> if the parameter belongs to some algebraic ring homomorphic >> with the real numbers, or some such. Are complex numbers also numbers? >> Is it meaningful to construct gmpy.mpqs out of them? What about >> Z/nZ? > > > If I could easily detect "this is a number" about an argument x, I'd > then ask x to change itself into a float, so complex would be easily > rejected (while decimals would mostly work fine, although a bit slowly > without some specialcasing, due to the Stern-Brocot-tree algorithm I > use to build gmpy.mpq's from floats). I can't JUST ask x to "make > itself into a float" (without checking for x's "being a number") > because that would wrongfully succeed for many cases such as strings. Hmm. If you want to do the generic conversion from numbers to rationals by going through float, then this is what you should do. Convert to float, and don't bother with checking whether it will succeed. Instead, if the type conversion gives an error, just return that to the caller. However, it also sounds odd that you are trying to do the to-rational-with-arbitrary-precision conversion by going through floats. Instead, if the argument is decimal, you really should do the division by the approprate base of 10, no? Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com