Implicit conversion to boolean in if and while statements

[Steven D'Aprano]

Rick Johnson wrote:

> 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
>> > some reason.
>>
>> Python is a fully object oriented language. It is *more* object oriented
>> than, say, Java.
> 
> Oh really? *chuckles*

Yes, really.


>> - everything in Python is an object, there is no distinction between
>> "boxed" 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
> language.

The essential features of OOP style are:

- dynamic dispatch -– Python has this

- encapsulation and/or multi-methods -- Python has this

- subtype polymorphism -- Python has this

- object inheritance or delegation -- Python has both of these

- open recursion (a special variable or keyword, normally called "this"
or "self", that allows method bodies to invoke another method of the same
object -- Python has this

- abstraction -- Python has this

http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts


What does not matter is syntax. Whether you write:

object#method           (OCaml)
object->method          (C++, Perl, PHP (non-static methods))
object::method          (PHP (static methods))
object <- method        (E)
[object method]         (Objective C)
object:method           (Lua)
object.method           (Java, Python, VisualBasic)
object method           (Smalltalk, some OOP dialects of Forth)
method object           (Other OOP dialects of Forth)
object \ method         (Pountain Forth)
method(object)          (Ada, Dylan, Matlab)
send method to object   (Hypertalk, OpenXION)


or something else even more exotic, is entirely irrelevant. What matters is
behaviour, not syntax.



>> 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?

Your reading comprehension is lacking.

Python allows procedural and functional STYLE syntax. It does not force you
to use a dot out of some slavish attention to an artificial philosophy of
programming language:

http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of-nouns.html

Python is pragmatic and human-centric. When OOP syntax is best, it will use
OOP syntax. If functional syntax is best, it will wrap objects in a thin
functional layer and use that. If procedural syntax is best, it will use
procedural-style coding. Where a pipeline or flow-based paradigm is best,
Python gives you iterators such as generator expressions. Most of the major
programming paradigms are available in Python, wrapped around a core that
is entirely objects.


>> In Python today, any() and all() will work perfectly on ANY ITERABLE
>> OBJECT, 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.
>> 
>> Under your suggestion, every iterable object has to implement an any()
>> method, and an all() method. Every iterable type has to repeat the same
>> old code as every other iterable type.
> 
> NOT IF PYTHON WERE TRULY 100% OOP!
> 
> If so, Python would have a supertype called "Collection" that wold define
> all methods that operate on collections. Some of these include:
> 
>  len, any, all, length, isempty, __getitem__, __setitem__, etc...
>  
> Then any collection subtype would inherit from this supertype and get the
> methods for free.

No they wouldn't. They would inherit an abstract method that raises an
error "Abstract method must be overridden by the subclass" for free.

Do you really think that *every* collection's __getitem__ could possibly use
the *same* implementation?

Should frozenset and set share the same __setitem__?

And what about objects which are not *collections*, and so cannot inherit
from Collection, but still need to implement some of those methods? Strings
are not collections. Should generators be forced to inherit __setitem__ so
that they can share any() and all() methods with lists? What length()
should a lazy generator expression return?

[...]
> Using built-in functions to operate on objects is foolish because you are
> placing extra burden on the programmer to know which /functions/ work with
> which /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!

If you can remember that lists have a sort() method and floats don't, then
you can remember that sorted() works on lists but not floats.



-- 
Steven