On Mar 1, 2:58 pm, Michael Torrie <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Tell Wall. But why not [ 2, 3 ]>= 2? Back to your question, another > > option is to not subclass. > > Umm, no. You need to actually read the posts before you respond to > them. His question was whether or not to throw an exception in this > case. He's *already* subclassed the type. > > The first question was, should he throw an exception. And given that > Python 3.0 will throw exceptions, he is justified in throwing exceptions > as well. I have no idea what he would lose by throwing an exception. I > have no idea how else he would do this. > > His second question was, would his code for implementing __gt__ (and > throwing exceptions) be likely efficient. That I cannot say.
Point taken. The is-a vs. has-a distinction was what I was looking at. Is it more work to the OP to disable the things in Int he doesn't want, or to enable those he does? On a tangent (you were alerted): A horse with three legs is a horse. A square with three sides is a square. A cup of coffee with no bottom is not a cup. If he doesn't throw an exception, he can compare to an arbitrary point, class-static, etc., post a message to a queue awaiting further instructions and block to its return, fire a synchronous callback, pause for user input, remove a certain element and set an op-abort flag, return a special value ( NoCompare= object() ), NaN, INF, &c., upgrade one or both operands, vary the behavior with class or instance, callback a coroutine omitting the point and assessing later, add it to a list of problem data to be treated by a superior, or take a special lunch break, after which the right-hand value is guaranteed to conform. You can try casting the RHV right-hand value to the required type too. Originally, exceptions came about as ways to respond to requests of a class hierarchy that fail to evaluate for the derived type, such as Ostrich().fly(), but expanded to include logic flow: do this this and this, except when file doesn't close correctly. In Python 1.0, a lot of classes set methods upon construction: init: self.data= data; self.__gt__= self.data.__gt__, and perhaps subclass that. Or move to C. In the trade, customers don't care what code made the program they bought. The company doesn't care what code made the program. Reinventing the wheel is cheap for certain wheels. Hallway full of doors; close some to get the product out sooner. What might we want down the road? What's down the road? Who is? In the hobbies, you can see an elaborate mixin to simplify work later, just for practice, or for the Zen-and-the art, like doing puzzles. class SpecialInt( Selective, int ): meths= Selective.numerics( int ) onlyif= [ partial( is_, int ), or_, partial( is_, SpecialInt ) ] It just costs performance-- product performance, even if not production team performance. from functools import partial from operator import is_, is_not assert partial( is_, int )( type( 2 ) ) assert partial( is_not, int )( type( 2.5 ) ) But: >>> class C: C ... Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in C NameError: name 'C' is not defined Can we have access to classes in their definitions? class C: delayed( 'C' ) works fine. If we don't want to permit calling a function on a half- executed class, then postcreator(or something) would have to be syntax. Class decorators can do it: * current= Current() @current.delay class SpecialInt: onlyif= [ partial( is_, int ), or_, partial( is_, current ) ] Similarly: * current= Current() class SpecialInt: onlyif= [ partial( is_, int ), or_, partial( is_, current ) ] current.delayedeval( SpecialInt ) But it starts to get really tangled: current= Current() @current.delay class SpecialInt: onlyif= [ partial( is_, int ), or_, current.partial( partial, is_, current ) ] where current.partial returns a delegation object that replaces current with the class current.delay wraps. If you don't want current to delegate too, then: current= Current() @current.delay class SpecialInt: onlyif= [ partial( is_, int ), or_, current.partial( partial, is_, current.ref ) ] may be next best. But all this is just to save two lines somewhere where you're allowed to use a custom wrap-in class, since Current is borderline library, and don't even mention 'standard'. However if it saves ten seconds in a coding competition, or captures the flash of an idea you get at 2 a.m. (make that 4 for the kids), then it's worth keeping around. import obscure. And class SpecialInt: onlyif= [ partial( is_, int ) ] SpecialInt.onlyif.extend( [ or_, partial( is_, SpecialInt ) ] ) sure is practical. -- http://mail.python.org/mailman/listinfo/python-list
