[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