PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!)

[Rick Johnson]

## START CODE ###########################################
def foo():
    # foo represents a patternless function
    # or method that returns a Boolean value
    # based on some internal test.
    #
    if 1==1:
        return True
    return False
#
# The fun begins when two tiny chars are forgotten,
# however, since the code is legal, python will happily
# give us the wrong answer.
#
if foo: # <- forgot parenthesis!
    print 'implicit conversion to bool bites!'
else:
    #
    # This block will NEVER execute because foo is
    # ALWAYS True!
    #
#
# Some introspection to understand why this happened.
#
print 'foo =', foo
print 'bool(foo) ->', bool(foo)
#
## END CODE #############################################

It's obvious i did not follow the syntactical rules of
Python, i understand that, however, there are three design
flaws here that are contributing to this dilemma:

    1. Implicit conversion to Boolean is evil

    2. Conditionals should never accept parameter-less
    functions. If you want to check if a callable is
    True or False, then use "if bool(callable)". Any
    usage of a bare callable in conditionals should
    raise SyntaxError.

    3. Implicit introspection is evil, i prefer all
    references to a callable's names to result in a CALL
    to that callable, not an introspection!
    Introspection should ALWAYS be explicit!

For a long time i thought Python's idea of a returning the
value of a callable-- who's name is unadorned with "(...)"
--was a good idea, however, i am now wholly convinced that
this design is folly, and the reason is two fold:

    1. Parenthesis should not be required for parameter-
    less functions. I realize this is a bit more
    complicated in languages like Python where
    attributes are exposed to the public, but still, not
    reason enough to require such onerous typing.

    2. Implicit introspection is evil. I would prefer an
    explicit method attached to all callables over a
    sugar for "callable.call". We should never consume
    syntactical sugars UNLESS they can greatly reduce
    the density of code (like math operators for
    instance!)