Why does list have no 'get' method?

[cokofreedom at gmail.com]

On Feb 8, 8:23 am, Carl Banks <pavlovevide... at gmail.com> wrote:
> 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

Can't you just make a subclass of Boolean and add methods to the true/
false, or am i running up a tree with a cat?

I think a clear problem with this is that, this is one area of grief
for some users with the Try/Except: clause usage, there are many other
examples of this where people would prefer one liners, and a good
argument not to allow one is because then you probably wouldn't have a
good defence against disallowing the other forms...

just-my-one-cent-ly's yours Coko