On 10/02/2014 18:45, Rick Johnson wrote:
## 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!)
This particular PyWart would immediately be caught if another PyWart,
namely the unittest module, were to be used to catch this programming error.
All of your preferences can be met by raising an issue on the bug
tracker and providing a patch that changes code, docs and test suites as
appropriate. Simples :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
--
https://mail.python.org/mailman/listinfo/python-list
