Terry Reedy wrote:
> "Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > class A(object):
> > def __init__(self):
> > raise NotImplemented
> >
> > We can regard class A as a "pure abstract" class. It is impossible
to
> > create instances of A.
>
> You see that parameter 'self'? When __init__ is called, it is bound
to an
> already created instance of A.
Yes. I've forgotten.
This would make sense and instantiable subclasses have to override
__new__.
class A(object):
def __new__(cls):
raise NotImplemented
def __init__(self):
self.x = 0
> How soon the last reference goes away I am
> not sure. If you change the raise statement to 'raise
> SomeException(self)', then that instance will become bound to the
'args'
> attribute of the resulting exception object. That exception object
can in
> turn be get captured by an 'except SomeException, obj' statement.
The
> binding of 'obj' persists after the except statement.
I considered the statement "raise Implemented" as kind of pattern: an
implementation that is at the same time a "declaration" for some client
who understands behavioural equivalence. One can not go much further
with the idea of scripting :)
On the other hand for real applications it may be wiser to use
decorators, because they are a standard and easy to use and to
understand.
This one would be completely appropriate:
def not_implemented(f):
setattr(f,"not_implemented",True)
return f
class A(object):
@not_implemented
def f(self):
pass
Allthough this one
class A(object):
def f(self):
raise NotImplemented
would be minimalistic and somehow innocent.
> To abort object creation, write a metaclass with __new__ and raise an
> exception there.
Yes.
>
> > Thinking in Python makes live easier because we can not only
> > check interfaces superficially but we can inspect the code and we
can
> > compare two code-objects on the behavioural level with a certain
> > accuracy.
>
> You are actually thinking in terms of the CPython implementation, not
> Python itself, which is fine as long as you don't expect
CPython-specific
> introspection to work with other implementations. But it is pretty
neat
> sometimes.
>
> Terry J. Reedy
I think it is scripting putting to the extreme. I don't know much about
the introspective capabilities of Jython and IronPython because I don't
use them but without them not even a variant of Pychecker will work for
either of the two Pychecker versions ( i.e. AST / bytecode ).
Ciao,
Kay
--
http://mail.python.org/mailman/listinfo/python-list
