On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> Antoine Pitrou wrote:
> > James Y Knight <foom <at> fuhm.net> writes:
> >> It seems that a separate method "_internal_close" should've been
> >> defined to do the actual closing of the file, and the close() method
> >> should've been defined on the base class as "self.flush();
> >> self._internal_close()" and never overridden.
> >
> > I'm completely open to changes as long as there is a reasonable consensus
> around
> > them. Your proposal looks sane, although the fact that a semi-private
> method
> > (starting with an underscore) is designed to be overriden in some classes
> is a
> > bit annoying.
>
> Note that we already do that in a couple of places where it makes sense
> - in those cases the underscore is there to tell *clients* of the class
> "don't call this directly", but it is still explicitly documented as
> part of the subclassing API.
>
> (the only example I can find at the moment is in asynchat, but I thought
> there were a couple of more common ones than that - hopefully I'll think
> of them later)
>
Queue.Queue in 2.* (and queue.Queue in 3.*) is like that too -- the single
leading underscore meaning "protected" ("I'm here for subclasses to override
me, only" in C++ parlance) and a great way to denote "hook methods" in a
Template Method design pattern instance. Base class deals with all locking
issues in e.g. 'get' (the method a client calls), subclass can override _get
and not worry about threading (it will be called by parent class's get with
proper locks held and locks will be properly released &c afterwards).
Alex
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
