Why does list have no 'get' method?

[Carl Banks]

On Feb 7, 8:44 am, Steve Holden <st... at holdenweb.com> wrote:
> bearophileH... at lycos.com wrote:
> > I'd like to know what others think about it, about this anti-feature.
> > What I can say is that other computer languages too think that boolean
> > operations must return boolean values only, so I am not alone in my
> > folly :-)
>
> Other languages do indeed refuse the temptation to short-circuit,

Short-circuiting isn't the issue here; a language can short circuit
and still return a boolean.

> but
> that doesn't mean that Python is wrong to do so. It's a design choice,
> and while you are free to disagree with it I imagine you would be
> pissing in the wind in attempting to get a change like that into Python 3.
>
> Most people like the semantics of "and" and "or" as they are.


I guess I'll agree with bearophile here; I think booleans should be
completely disjoint from all other types, as they are in Java.  "and",
"or", and "not" should accept only boolean operands and return only
boolean results.

I don't deny that it's convenient to use "or" that returns the first
true value, or that it's sometimes a marginal improvement in clarity.

I just think this idiom is too error prone, and very often too
misleading, to justify its convenience.  There's ordinary
carelessness, of course, where someone writes a function like this:

def op(datum=None):
    result = datum or default

while not stopping to consider that the empty string would be a legal
value for datum in this case.  But there's a more insidious danger
that can't be chalked up to carelessness: when the acceptable values
for datum change *after* the function is written.  This leads to
subtle breakage.

As far as the user is concerned, this function's correct behavior is
to "use the default when the argument is not specified", but as-is the
function is not robust to future changes or uses.  The function is a
poor, non-robust implementation of the desired behavior.

To me this feels like a ticking bomb, a bug waiting to emerge from
it's egg.


More generally: I find that the boundary between what Python considers
to be true and false rarely corresponds exactly to what I'm trying to
do in cases like the above.
Usually the true/false test only works for certain set of expected
values that I have in my mind.  When the acceptable values are
generalized, when you want to expand this function's role, does the
true/false test still work?  I find it rarely does.


The Python treatment of booleans is, by far, my biggest gripe with
Python.  (Which, you know, is a pretty good thing to have as a biggest
gripe.)


Carl Banks