Implicit conversion to boolean in if and while statements

[Mark Janssen]

On Fri, Feb 8, 2013 at 9:48 AM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote:
>> Rick Johnson wrote:
> Just because /everything/ in Python is an object does not mean that Python is 100% OOP.

The whole idea of "make everything an object" is possibly a misguided
sense of puritanism anyway.   I wouldn't harp on that point to much.
But I really like your other developments.  Like the following

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

I think this is a great idea and fixes a language wart which put
irrelevant methods into the builtin namespace.

> Then any collection subtype would inherit from this supertype and get the methods for free.

Yes.  OOP encapsulation.  But I question whether strings should be
considered collections.  This is a spurious usage issue, not something
in an integrated object model (see below on what I mean).

>> 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 syntax.
> 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!

Exactly.  This gets us closer to the real Python3000 that I've been
waiting for....

> 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:
>
>   sum, len, any, all, enumerate, map, max, min, reversed, sorted, zip
>
> can only be applied to sequence types, or subtypes of a sequence type. So using a /real/ OOP paridigm we would do the following:
>
> ## START TRUE OOP PARIDIGM ##
> [[snip]]

This is a great start, I think, but I think it's time to really
re-evaluate the whole data model again.  Before Python was trying to
"have everything", and have the flexibility to adapt for everyone, but
sometimes I think there's too much flexibility  and options and it
leads to sloppiness.  I would argue it's time for a refactor and
re-think the object model.

> class Object(SuperType):
>     def dir
>     def help
>     def id
>     def isinstance?(Type)
>     def issubclass?(Type)
>     def super
>     def type

I like the general line-of-thought, but some of these are
questionable.  I think it's essential to have help() outside any class
-- the built-in, global methods serve an important purpose of setting
the culture for a language, and help, (and my proposed test()) builtin
are part of (or would be) the community.

> class SequenceBase(Object):
>     def sum
>     def filter(proc)
>     def map
>     def max
>     def min
>     def reverse
>     def reduce(proc)

Here again, you see how the early python community put these in the
global namespace because of the bias that they had such (admittedly()
cool builtin collection types in the language.  But now, it's
interesting to reconsider these ideas.

> ## 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), not global functions applied to objects in some haphazard fashion that some self-appointed dictator pull from his backside due to his fear of true OOP style!

That's not quite fair to the BDFL; you're criticizing the community
that made Python great.  That, of course, doesn't mean that it's still
logical to keep them out there in the global scope, exposed for all to
see.

> 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 longs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP lingerie on the weekends.

That's a funny quote, besides its questionable accuracy, but your
initial sentences point out that having a unified data model might
actually be of use.  A unified data model does for data what lexical
definitions and parsers do for code:  organize it in a well-defined
way that is a *complete* specification for all possible data
organizations.  (But see my other posts about that.... ;^)

Mark
Tacoma, Wa