Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!194.134.4.91.MISMATCH!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!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.007 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'received:134': 0.05; 'permitted': 0.07; 'builtin': 0.09; 'classes.': 0.09; 'feature,': 0.09; 'here?': 0.09; 'patch.': 0.09; 'restriction': 0.09; 'python': 0.11; 'jan': 0.12; '"in': 0.16; 'bool': 0.16; 'reedy': 0.16; 'singleton': 0.16; 'subclass': 0.16; 'subject: \n ': 0.16; 'subject:OOP': 0.16; 'subject:object': 0.16; 'subject:possible': 0.16; 'subject:programming': 0.16; 'subject:type': 0.16; 'exception': 0.16; 'language': 0.16; 'wrote:': 0.18; 'looked': 0.18; '>>>': 0.22; 'header:User-Agent:1': 0.23; 'case.': 0.24; 'documented': 0.24; 'either.': 0.24; "shouldn't": 0.24; 'mon,': 0.24; 'class.': 0.26; 'subject:/': 0.26; 'header:In-Reply-To:1': 0.27; 'idea': 0.28; 'leave': 0.29; "doesn't": 0.30; 'getting': 0.31; "d'aprano": 0.31; 'object.': 0.31; 'steven': 0.31; 'them?': 0.31; 'class': 0.32; 'maybe': 0.34; 'classes': 0.35; 'case,': 0.35; 'more,': 0.35; 'one,': 0.35; 'but': 0.35; 'there': 0.35; "didn't": 0.36; 'possible': 0.36; 'should': 0.36; 'two': 0.37; 'being': 0.38; 'to:addr:python-list': 0.38; 'issue': 0.38; 'pm,': 0.38; 'does': 0.39; 'itself': 0.39; 'to:addr:python.org': 0.39; 'major': 0.40; 'liked': 0.60; 'most': 0.60; 'first': 0.61; 'making': 0.63; 'real': 0.63; 'skip:n 10': 0.64; 'decided': 0.64; 'subject:The': 0.64; 'chance': 0.65; 'needing': 0.65; 'here': 0.66; 'believe': 0.68; 'other.': 0.75; '10:32': 0.84; 'case?': 0.84; 'experiment': 0.84; 'wanted,': 0.84; '2013': 0.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAKwTbVGGuA9G/2dsb2JhbABQwViCaoEegxMBAQV4EQsYCRYPCQMCAQIBRRMIAogQrEKHKYkRiW+FJxaDLAOXBYV0iyCBVYE4 Date: Tue, 16 Apr 2013 11:07:38 +0200 From: Antoon Pardon User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: python-list@python.org Subject: Re: The type/object distinction and possible synthesis of OOP and imperative programming languages References: <516bd241$0$29872$c3e8da3$5496439d@news.astraweb.com> <516C3C44.6010706@rece.vub.ac.be> <516cb85b$0$29977$c3e8da3$5496439d@news.astraweb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 46 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1366103332 news.xs4all.nl 2681 [2001:888:2000:d::a6]:49707 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:43665 Op 16-04-13 05:17, Terry Jan Reedy schreef: > On 4/15/2013 10:32 PM, Steven D'Aprano wrote: >> On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote: > >>> Some builtin classes cannot be subclassed. There is an issue to >>> document >>> which better. That does not mean that it is not a class. >> >> >> I think it is also important to document whether that is a language >> feature, or a mere restriction of the implementation. There is an >> important distinction to be made between: >> >> "In CPython, you cannot subclass slice or FunctionType. Other Pythons >> may >> have more, or fewer, restrictions." >> >> and: >> >> "No language that calls itself Python is permitted to allow slice and >> FunctionType to be subclassable." >> >> >> If I had a say in this, I would vote for the first case, with the >> possible exception of documented singleton types like NoneType and bool. > > I will keep the above in mind if I write or review a patch. here are 4 > non-subclassable builtin classes. Two are already documented. Bool in > one, forget which other. I believe it was recently decided to leave > the other two as is given the absence of any practical use case. Why should there be a practical use case here? Since classes are in general subclassable, shouldn't you have a reason to not make them so instead of people needing to give you a practical use case before you treat them as you do most of them? I once had an idea of a slice-like class that I would have liked to experiment with. As things were I didn't get far because slice not being subclassable was a major hurdle in getting it practical. Would the end result have been a practical use case? I don't know, I didn't get the chance to find out because making a class that looked like a slice didn't work either. Python wanted, maybe still wants, a real slice in a number of circumstances and not a ducktyped slice-like object. Now maybe there are good reasons for slice not being subclassable but there not being a practical use case doesn't seem to be one in this case.