[Tutor] Don't understand this class/constructor call syntax
Steven D'Aprano
steve at pearwood.info
Sun Jul 24 09:07:14 CEST 2011
dave wrote:
> Thank you for the two explanations. I think I have a good idea of what is
> going on now with the arguments and keyword arguments.
>
> My only remaining question is the pad_for_usrp argument. The default value is
> True so I thought it was a boolean and couldn't have anything to do with the
> "self<transmit_path>" that was passed to it. However, I can probably puzzle
> that out by looking at how it's used in the code.
I don't know why a transmit_path instance is being passed as a pad_*
flag, but you may not be aware that in Python, any object can be used as
if it were a boolean, not just True and False.
Generally, the rule is:
"something" is considered true-valued;
"nothing" is considered false-valued.
So, among the built-ins, we have "nothings" such as:
0
0.0
'' # empty string
[] # empty list
{} # empty dict
() # empty tuple
set([]) # empty set
None
are all considered to be false in a boolean context. And we have
"somethings", such as:
42
0.125
'x'
[None, 42, '*']
{0: None}
object()
etc. all considered to be true in a boolean context.
(Note that among strings, only the empty string counts as nothing. The
strings 'nothing', 'empty', 'false', 'not a thing', 'nada', 'not a brass
farthing', "dry as a dingo's donger" etc. are non-empty strings and
therefore count as true-values.)
True and False are merely the canonical flags. In general, functions and
methods are expected to be liberal in what they accept (any object can
be used as if it were a boolean) and conservative in what they return
(if returning a flag, you should return True/False, or 1/0 if you need
to support *really* ancient versions of Python).
--
Steven
More information about the Tutor
mailing list