osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tutor] beginning to code


Steve D'Aprano wrote:

> [snip: offensive statements]
>
> Your insistence on adding the entirely superfluous, unnecessary

Please acquaint yourself with the definition of superfluous,
as in most i have seen, the actual word "unnecessary" is
part of the definition.

> and distracting "== True" at the end of something which is
> already True or False demonstrates a lack of fluency in the
> language and difficulty in reasoning about boolean logic.

Steve, it one thing for you to disagree with me (even to the
point of passionate appeals), but it is quite another to
suggest that my "fluency of the Python language" or my
"reasoning about boolean logic" is flawed.

Python is a programming language, not a formal logic, and i
can assure you, i understand Python semantics and formal
logic just fine.

My complaint that Python's conditional logic forms: (1)
implicitly cast objects to boolean, and (2) and rely on an
underlying and unintuitive design which has arbitrarily
assigned boolean values to objects -- is not a result of a
misunderstanding on my part, no, it a result of my utter
distaste for implicit conditional logic forms. 

Consider the currently accepted form of conditional logic:

    if someObject:
        # do something
        
In this implicit code example, Python is doing two "magical"
things:

    (1) Python3 is implicitly casting `someObject` to a
    boolean value by silently calling
    `someObject.__bool__()`. 
    
    Of course, in Python<3 there was no __bool__ dunder
    method, so you'd have to define __nonzero__ or __len__
    to achieve the same thing. And for those who don't know
    about this difference, consider the following Python 2.x
    code:
    
        >>> class FalseFoo(object):
        ...     def __len__(self):
        ...         return 0
        >>> falseFoo = FalseFoo()
        >>> bool(falseFoo)
        False
        >>> class TrueFoo(object):
        ...     def __len__(self):
        ...         return 1
        >>> trueFoo = TrueFoo()
        >>> bool(trueFoo)
        True
        
    Hmm, in light of this revelation, one could argue that
    __bool__ was only introduced to correct a semantical
    inconsistency that existed between the bool() function
    and the dunder method it called, namely: __nonzero__ or
    __len__ (depending on which was defined). All other
    builtin functions (i can think of) map perfectly to
    intuitively named dunder methods (len -> __len__, dir ->
    __dir__, etc...). So, obviously, the devs are concerned
    about "source code semantics", or they would have not
    have introduced __bool__.
        
    (2) Python is, in essence, converting the source code
    syntax of:
    
        if someObject:
        
    to:
    
        if BOOLEAN_VALUE_OF_SOMEOBJECT:
    
    Which, although the result of such a conversion (a
    Boolean) will be perfectly symmetrical with formal logic
    statements, the conversion is not obvious, because it
    happens behind the curtains.
            
So with that simple statement, two magical and unobvious
actions are occuring behind the curtain. IMO, such non-
obvious conversions are a violation of the "human readable"
goal of Python source code. Magic is not obvious. And
implicit conditional logic is not "human readable".