[Python-Dev] Possible py3k io wierdness (original) (raw)
Alex Martelli aleaxit at gmail.com
Mon Apr 6 02:28:51 CEST 2009
- Previous message: [Python-Dev] Possible py3k io wierdness
- Next message: [Python-Dev] Possible py3k io wierdness
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
Antoine Pitrou wrote: > James Y Knight <foom fuhm.net> writes: >> It seems that a separate method "internalclose" 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.internalclose()" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090405/7ae67f2c/attachment.htm>
- Previous message: [Python-Dev] Possible py3k io wierdness
- Next message: [Python-Dev] Possible py3k io wierdness
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]