Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.020 X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; 'python,': 0.02; 'attribute': 0.07; 'think,': 0.07; 'calls.': 0.09; 'lookup': 0.09; 'cc:addr:python-list': 0.11; '(other': 0.16; '*should*': 0.16; '__init__,': 0.16; 'itself,': 0.16; 'kwargs': 0.16; 'subclass': 0.16; 'subject:object': 0.16; 'library': 0.18; '(where': 0.19; 'machine': 0.22; 'example': 0.22; 'cc:addr:python.org': 0.22; "aren't": 0.24; "haven't": 0.24; '(or': 0.24; 'cc:2**0': 0.24; 'cc:no real name:2**0': 0.24; 'header:In-Reply-To:1': 0.27; 'idea': 0.28; 'point': 0.28; 'function': 0.29; 'leave': 0.29; "doesn't": 0.30; 'message-id:@mail.gmail.com': 0.30; 'getting': 0.31; 'grouping': 0.31; 'safely': 0.31; 'class': 0.32; 'becomes': 0.33; 'subject:the': 0.34; 'problem': 0.35; 'classes': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'crazy': 0.36; 'instances': 0.36; 'words,': 0.36; 'done': 0.36; 'method': 0.36; 'possible': 0.36; 'should': 0.36; 'wrong': 0.37; 'work?': 0.38; 'whatever': 0.38; 'that,': 0.38; 'little': 0.38; 'how': 0.40; 'chain': 0.60; 'most': 0.60; 'new': 0.61; 'complete': 0.62; 'making': 0.63; 'happen': 0.63; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'specializing': 0.68; 'yourself': 0.78; 'habit': 0.91; 'received:mail-wi0-x229.google.com': 0.91; 'weaknesses': 0.91; 'children.': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t1KuNbPHv6T6cRH+nJv8r8DwPEvyn5pdyeLbrLfsBH0=; b=QI8AQGROb4yYn+0ou3DVoPIqW3YYXeiPdSbxrJ8iv0pEtWjAKdP3kgi5DkFL9JXuMU JDJ2nSifGsP0TkXTq611uNNQMjf2osjUEJYtpusCnMezc7uclhkT9W6eUqG5CemDePtw XMuvWEl+og/jk62x+1vZFrPAMMZYHPJBj1dRLXu//G1GNLfc7EkfpoXUNYxYJIHvAuf1 3wZ2O5/nckFBy+wJPNqUFEKFw1zNXB4fft9JaIBPjsq6FmC5cKwFpIlfiqs+7rg/fllZ jlYxfmusaz2+QHJJiCiqxj7LmUvxPs6dBZ9U5eTE1Ugkn2YmaafiqfUytLLOzwVhPcsh SeXg== MIME-Version: 1.0 X-Received: by 10.194.133.106 with SMTP id pb10mr720766wjb.62.1372199242086; Tue, 25 Jun 2013 15:27:22 -0700 (PDT) In-Reply-To: References: <15ba0011-bbf1-42f7-b3ea-1c1d4b70e56b@googlegroups.com> <51c66962$0$29999$c3e8da3$5496439d@news.astraweb.com> <20130623133546.GA2308@capricorn> <51c723b4$0$29999$c3e8da3$5496439d@news.astraweb.com> <51C74D6E.6030200@rece.vub.ac.be> Date: Tue, 25 Jun 2013 15:27:21 -0700 Subject: Re: What is the semantics meaning of 'object'? From: Mark Janssen To: Chris Angelico Content-Type: text/plain; charset=ISO-8859-1 Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 31 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372199734 news.xs4all.nl 15981 [2001:888:2000:d::a6]:35788 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49199 > The main problem is getting to the top/end of the call chain. Classic > example is with __init__, but the same problem can also happen with > other calls. Just a crazy theory, but would it be possible to > construct a black-holing object that, for any given method name, > returns a dummy function that ignores its args? (Other forms of > attribute lookup aren't going to be a problem, I think, so this can be > just methods/functions.) Then you just subclass from that all the > time, instead of from object itself, and you should be able to safely > call super's methods with whatever kwargs you haven't yourself > processed. Would that work? > > Caveat: I have not done much with MI in Python, so my idea may be > complete balderdash. Here's how it *should* be made: the most superest, most badassed object should take care of its children. New instances should automatically call up the super chain (and not leave it up to the subclasses), so that the parent classes can take care of the chil'en. When something goes wrong the parent class has to look in and see what's wrong. In other words, this habit of specializing a Class to make up for the weaknesses of its parent are THE WRONG WAY. Instead, let the specialization start at the machine types (where it doesn't get more specialized), and work UPWARDS. Let the standard library make the grouping (or collection types) to point to the standard way of data structuring, and then everything else becomes little mini-apps making a DataEcosystem. --mark