X-Received: by 10.224.190.193 with SMTP id dj1mr3669297qab.6.1360345723857; Fri, 08 Feb 2013 09:48:43 -0800 (PST) X-Received: by 10.49.1.162 with SMTP id 2mr514604qen.2.1360345723836; Fri, 08 Feb 2013 09:48:43 -0800 (PST) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!p13no4224080qai.0!news-out.google.com!k2ni19249qap.0!nntp.google.com!p13no4224077qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.python Date: Fri, 8 Feb 2013 09:48:43 -0800 (PST) In-Reply-To: <511516db$0$29969$c3e8da3$5496439d@news.astraweb.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.196.111.123; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj NNTP-Posting-Host: 70.196.111.123 References: <5002a1f9$0$29995$c3e8da3$5496439d@news.astraweb.com> <7b027612-a07e-40f9-8ad2-3e95c5440482@googlegroups.com> <86872ad2-fda0-403b-9f18-d1cb18e41860@t32g2000yqd.googlegroups.com> <50039290$0$29978$c3e8da3$5496439d@news.astraweb.com> <9309333c-13a0-464c-bd94-9c682363b8c9@googlegroups.com> <511516db$0$29969$c3e8da3$5496439d@news.astraweb.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Implicit conversion to boolean in if and while statements From: Rick Johnson Injection-Date: Fri, 08 Feb 2013 17:48:43 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: csiph.com comp.lang.python:38469 On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote: > Rick Johnson wrote: > > > GvR has always been reluctant to incorporate full OOP machinery for som= e > > reason. > > Python is a fully object oriented language. It is *more* object oriented > than, say, Java. Oh really? *chuckles* > - everything in Python is an object, there is no distinction between "box= ed" > and "unboxed" variables; Just because /everything/ in Python is an object does not mean that Python = is 100% OOP. This fact is just one of the many attributes of a 100% OOP lan= guage. Yes, Python allows OOP style, but python is NOT 100% OOP! Ruby on th= e other hand /is/ 100% OOP. Although it has identity issues like Python. Ru= by thinks it's multi-paridigm and Python thinks it's a good example of OOP.= Neither are correct. > - modules are objects; > > - functions and methods are objects; > > - classes are objects in Python, and have their own class (the metaclass)= ; > > - metaclasses themselves are also objects, and have classes of their own; > > - it's objects all the way down, at least until you reach "type" itself, > which is bootstrapped into existence by the compiler. > > > Although Python is fully object-oriented, it does not insist on one > particular style of object syntax. It allows procedural and functional > style syntax as well. Well you just defeated yourself. How can Python be 100% OOP and then allow = other paradigms?=20 > > I am not suggesting that Python be 100% OOP, HELL NO! But > > collections should have had an "isempty" method from the beginning. But > > the same argument could be made against len, any, all, etc... >=20 > No they shouldn't. >=20 > [...] >=20 > Python functions operate as *protocols*. any() and all(), for example, ar= e > excellent examples of why your suggestion fails: the principle of "Don't > Repeat Yourself". >=20 > In Python today, any() and all() will work perfectly on ANY ITERABLE OBJE= CT, > for free. The developer of that object doesn't need to do anything to > support any() and all(), all she has to do is make it iterable. >=20 > Under your suggestion, every iterable object has to implement an any() > method, and an all() method. Every iterable type has to repeat the same o= ld > code as every other iterable type. NOT IF PYTHON WERE TRULY 100% OOP!=20 If so, Python would have a supertype called "Collection" that wold define a= ll methods that operate on collections. Some of these include: len, any, all, length, isempty, __getitem__, __setitem__, etc... =20 Then any collection subtype would inherit from this supertype and get the m= ethods for free. >=20 > [...] > See all the pointlessly duplicated code? Now each one needs tests, and > documentation, and the amount of duplication goes through the roof. > > Now, a developer of merely average intelligence will see all that duplica= ted > code, and factor it out into a global function (two actually, one for > any(), one for all()): Only if that developer does not understand sub-typing! All he has to do is = write the method ONE TIME in a super-type, and then inherit the method into= ANY number of sub-types for free. Now, if he wants to pervert the usage of= a method to fit some niche, THEN he will need to overload the method and p= rovide proper return value. > But a developer of above average intelligence will recognise that all tho= se > x.any() boilerplate methods are *pointless and stupid*, since you have a > function that does everything you need, for every possible iterator, for > free. All you need do is use any(obj) syntax instead of obj.any() syntax, > which also saves one keystroke. > > And a *really* smart language designer will have realised this ahead of > time, and designed the language to encourage the use of protocols like > this, instead of insisting on the slavish application of obj.method synta= x. Using built-in functions to operate on objects is foolish because you are p= lacing extra burden on the programmer to know which /functions/ work with w= hich /types/. The *only* functions that should be global are the kind that = will work on *ANY* object. But then again, the Object type could hold these= methods! len, all, and any (just to name a few) only work for collections types and = as such should be methods of these types. The global functions: =20 sum, len, any, all, enumerate, map, max, min, reversed, sorted, zip =20 can only be applied to sequence types, or subtypes of a sequence type. So u= sing a /real/ OOP paridigm we would do the following: ## START TRUE OOP PARIDIGM ## class Object(SuperType): def __class__ def __delattr__ def __doc__ def __format__ def __getattribute__ def __init__ def __new__ def __repr__ def __setattr__ def __sizeof__ def __str__ def __subclasshook__ def true? # aka: bool def callable? def compare(other) def dir def hash def help def id def isinstance?(Type) def issubclass?(Type) def super def type class SequenceBase(Object): # Methods from object are free def __add__ def __contains__ def __delattr__ def __delitem__ def __delslice__ def __eq__ def __ge__ def __getitem__ def __getslice__ def __gt__ def __iadd__ def __imul__ def __iter__ def __le__ def __lt__ def __mul__ def __ne__ def __reduce_ex__ def __rmul__ def __setitem__ def __setslice__ def __subclasshook__ # # Interface # def iterator def length def sum def any def all def enumerate def filter(proc) def frozenset def map def max def min def reverse def reduce(proc) def slice def sort def zip =20 class MySequencyThing(SequenceBase): # do something here =20 class List(SequenceBase): # Methods from SequenceBase and Object are free! # # Interface # def append def count def extend def index def insert def pop def remove def reverse def sort =20 class MyListyThing(List): # do something here ## END TRUE OOP PARIDIGM ## You see, 100% OOP uses encapsulation, inheritance, sub-typing, etc, etc... = But most fundamental to OOP is interface (methods belonging to objects), no= t global functions applied to objects in some haphazard fashion that some s= elf-appointed dictator pull from his backside due to his fear of true OOP s= tyle! Python is not 100% OOP. Heck you cannot fairly apply a specific percentage = level because Python's level of OOP is defined by each user of the language= . The best way to describe Python is as promiscuous language who secretly l= ongs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP li= ngerie on the weekends.