On Sunday 31 March 2002 23:21, Aahz wrote: ... > in several months, but never mind). I need to be able to accept floats, > ints/longs, and string representations of numbers, all at the maximum > possible precision for each type. I suppose I could create helper ... > (Alex, IIRC, the last time we had this discussion you agreed that I > didn't have any choice.) The "maximum possible precision" constraint may leave you no choice (within current Python, bereft of PEP 246) for e.g. longs and floats, but I still don't see why it's better to reject UserString than to test with a try/except on x+''. > Note that these days with new-style classes the situation is actually > better: inherit from the built-in types, and isinstance() works > correctly. To me, this means you're basically forced to use inheritance (which is mostly meant as inheritance of implementation) for _flagging_ purposes. I find it detestable, and the inability of multiply inheriting from several builtin types still leaves me in a quandary when I want to flag my type's compatibility with more than one of them -- I have to choose by guessing which of them I'm more liable to be typechecked against... Unicode doesn't inherit from str, yet by the 'flagging' criterion it should, for example (or dearly hope every deuced isinstance-happy function in every deuced library remembers in its deuced typechecks to add one for Unicode next to the one for str). gmpy.mpf instances don't subclass float and it would be (IMHO) an utterly silly thing for them to do so -- yet they WOULD be usable if, instead of by isinstance, they were tested by their abilities, in many cases. And what builtin are you subclassing your BCD class from to make its instances usable in other frameworks full of those isinstance checks...? There is no perfect solution, without PEP 246, but it seems to me that (except where peculiar specific conditions such as the need to lose no precision force the issue) isinstance tends to be more imperfect than others. Incidentally, to clarify: _with_ PEP 246, the need to lose no precision at all might _still_ give problems; e.g., if you asked an mpf to conform to float, you might indeed be losing significance -- in this case, somebody (you as the BCD maintainer, I as the gmpy maintainer, OR, crucially, any third party non-invasively to both packages) would have to code a specific adapter. The PEP246 advantage would be to GIVE said 3rd party (or either of us) the right peg on which to hang such a specific adapter -- it still wouldn't magically write one for us:-). Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4