bool([x])
Convert a value to a Boolean, using the standard truth testing procedure.
In this context, what exactly a "value" is referring to ?
For instance,
>>> x=42
>>> bool(x=5)
True
>>>
but _expression_ :
x=42
has no value.
That's because bool(x=5) isn't doing what you think.
>>> bool(y=5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'y' is an invalid keyword argument for this function
bool(x=5) is just passing the value 5 as the argument "x" to the function.
"value" means just what you'd think- any constant or any value that's
been assigned to.
>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Cute. What's happening here is that `x=5` isn't really an expression.
It's passing a value to the named parameter `x`, specified in the
definition of `bool`. Try it with something else:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> bool(y=5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'y' is an invalid keyword argument for this function
Mel.
"x=42" is an assignment statement, not an expression.
In "bool(x=5)", "x=5" is also not an expression. It's passing the
expression "5" in as the parameter x, using a keyword argument.
> "x=42" is an assignment statement, not an expression.
Right, I was confounding with C ;)
In fact, respect to this question, the documentation makes things
unambiguous :
-----------------
In contrast to many other languages, not all language constructs are
expressions. There are also statements which cannot be used as
expressions, such as print or if. Assignments are also statements, not
expressions.
-----------------
> In "bool(x=5)", "x=5" is also not an expression. It's passing the
> expression "5" in as the parameter x, using a keyword argument.
You are probably right but how do you deduce this brilliant
interpretation from the wording given in the documentation ?
Look at your original post, which contains the excerpt from the docs
that you put there:
>
> bool([x])
> Convert a value to a Boolean, using the standard truth testing
> procedure.
>
As you can see, the parameter name is 'x'.
~Ethan~
By also learning the language syntax. ‘foo=bar’ within the parameters to
a function call will always mean binding a value to a keyword argument.
Just as the function docstring should not spend any space to explain
what the parens mean, it should not spend any space to explain how to
pass keyword arguments.
--
\ “When [science] permits us to see the far side of some new |
`\ horizon, we remember those who prepared the way – seeing for |
_o__) them also.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney
> > bool([x])
> > Convert a value to a Boolean, using the standard truth testing
> > procedure.
> >
>
> As you can see, the parameter name is 'x'.
OK, your response is clarifying my point ;)
I didn't realize that in the bool([x]) syntax, identifier x refers to a
"genuine" argument [I was considering x as referring to a "generic"
object having a boolean value].
Nevertheless, compare with the definition the doc provides for the
builtin function dir():
dir([object])
[definition omited, just observe the declaration syntax]
Now, lets make a try
>>> dir(object="Explicit is better than implicit")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: dir() takes no keyword arguments
>>>
Not very meaningful, isn't it ?
The error says it unambiguously, dir() does not take *keyword*
arguments; instead dir() takes *positional* argument:
dir("Explicit is better than implicit")
No one is saying that every instance of "foo([arg])" in the docs means that the
given argument is named such that it is available for keyword arguments. What
people are saying is that for bool(), *that happens to be the case*.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
> No one is saying that every instance of "foo([arg])" in the docs means
> that the given argument is named such that it is available for keyword
> arguments. What people are saying is that for bool(), *that happens to
> be the case*.
>
what a piece of luck! ;)
>> dir([object])
>> Not very meaningful, isn't it ?
>
> The error says it unambiguously, dir() does not take *keyword*
> arguments; instead dir() takes *positional* argument:
>
> dir("Explicit is better than implicit")
I think the point is that both cases are documented exactly the same.
--
Grant
In what case(s) would a keyword arg to bool be reasonable?
It's just an implementation detail. It's not worth the electrons wasted in this
thread already.
> bool(x=5) is just passing the value 5 as the argument "x" to the function.
>
Anyway, passing x as a keyword argument to the bool function appears to
be very rare : i did a regexp search for about 30000 source-code Python
files (among them official Python source-code, Django, Sphinx, Eric
source-code and many more sources of valuable Python code) and I didn't
find even one.
Who would use keyword arguments with a function that takes only one arg anyway?
ChrisA
> Who would use keyword arguments with a function that takes only one arg
> anyway?
It's hard to imagine. Maybe somebody trying to generalize function calls
(trying to interpret some other language using a python program?)
# e.g. input winds up having the effect of ..
function = bool
name = 'x'
value = 'the well at the end of the world'
## ...
actions.append ((function, {name:value}))
## ...
for function, args in actions:
results.append (function (**args))
Not something I, for one, do every day. But regularity in a language is
good when you can get it, especially for abstract things like that.
I can sort of guess that `dir` was perhaps coded in C for speed and doesn't
spend time looking for complicated argument lists.
Python is a pragmatic language, so all the rules come pre-broken.
Mel.
I presume that it is agreed they the following is a satisfactory outcome:
*** Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32. ***
>>> bool(x=0)
False
>>> bool(x=1)
True
>>>
Colin W.
> Python is a pragmatic language, so all the rules come pre-broken.
+1 QOTW
--
\ “Science shows that belief in God is not only obsolete. It is |
`\ also incoherent.” —Victor J. Stenger, 2001 |
_o__) |
Ben Finney
+1 QOTW
Wrong structure.
Better do
function = bool
value = 'the well at the end of the world'
## ...
actions.append((function, (value,), {}))
## ...
for function, args, kwargs in actions:
results.append(function(*args, **kwargs))
or maybe even better (taking care for closures):
function = bool
value = 'the well at the end of the world'
## ...
actions.append(lambda val=value: function(val))
## ...
for function in actions:
results.append(function())
Can this become:
results = [function() for function in actions]
Chris Angelico
> or maybe even better (taking care for closures):
>
> function = bool
> value = 'the well at the end of the world'
> ## ...
> actions.append(lambda val=value: function(val))
> ## ...
> for function in actions:
> results.append(function())
Or yet even better:
class Job(object):
def __init__(self, target, *args, **kwargs):
self.target = lambda: target(*args, **kwargs)
def __call__(self):
return self.target()
in order to do
actions.append(Job(function, val))
actions.append(Job(function, x=val))
and then (thanks, Chris...)
results = [function() for function in actions]
or maybe (additionally or alternatively)
class ActionQueue(list):
def addJob(self, target, *args, **kwargs):
self.append(lambda: target(*args, **kwargs))
def __call__(self):
if 0: # first thought
for job in self:
yield job()
else: # second thought - clean up...
while self:
job = self.pop(0)
yield job()
with
actions = ActionQueue()
actions.addJob(function, val)
actions.addJob(function, x=val)
results = list(actions()) # for collecting them and having them at once
# with generator, all call results can as well be emitted as soon as
they are available - depending what shall be done with the results
mmm... too much imagination I think... ;-)
Thomas
results = map(apply, actions)
from functools import partial
actions.append(partial(function, val))
actions.append(partial(function, x=val))
Cheers,
Ian
Sadly not in Python 3, where map is lazy and you need to add a call to
list to make it equivalent to the list comp.
--
Steven