Defining a method final
whisper at oz.net
Tue Jun 11 16:19:53 CEST 2002
I think the point of what he is asking for has been missed. Final methods
are not necessisarily private, it means they can't be redefined
("overridden") in derived classes, thus freezing the semantics of the
A plausible scenario for something like this is a class that wraps hardware.
While I might like to create derived classes for text or binary I/O on this
widget, the exact sequence of manipulating the hardware is tricky and can
result in expensive damage if not done exactly right. Therefore, I don't
want derived classes changing the read or write methods of the base class.
In another post, I suggested the idea of pulling the base classes methods
down into the dictionary of the derived classes during __init__ I don't know
if this is a pythonic way to do things (it strikes me as being so), but I
think it would have the desired effect.
Seattle, WA USA
> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Eric Brunel
> Sent: Tuesday, June 11, 2002 8:36
> To: python-list at python.org
> Subject: Re: Defining a method final
> Emile van Sebille wrote:
> > Accepted practice is to use a single underscore for objects to be
> > considered private. This does not prevent their use, but strongly
> > signals that re-use ought not to be done.
> >>>> class Test:
> > ... def _private(self): pass
> > ...
> Python now have an "official" means to make attributes private by
> them with a double-underscore. And it *does* prevent their use or
> class A:
> def __private(self): pass
> class B(A):
> o = B()
> results in:
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> AttributeError: B instance has no attribute '__private'
> Regarding the original question (final methods), it has however obvious
> - the method can be *redefined*: that doesn't mean it can be overloaded,
> but class B can have its own __private method
> - the method is actually *private*, which means that neither sub-classes,
> nor "outside" classes can call it.
> I don't think that actual final methods can be defined in Python...
> - Eric Brunel <eric.brunel at pragmadev.com> -
> PragmaDev : Real Time Software Development Tools -
More information about the Python-list