How to subclass a built-in int type and prevent comparisons

[castironpi at gmail.com]

On Mar 1, 2:58 pm, Michael Torrie <torr... at gmail.com> wrote:
> castiro... at gmail.com 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.