On 2 March 2017 at 07:03, David Mertz <me...@gnosis.cx> wrote:
> On Wed, Mar 1, 2017 at 11:13 AM, Abe Dillon <abedil...@gmail.com> wrote:
>
>> I'd like to +1 this proposal. It should be trivial to implement. It won't
>> break backward compatibility. It's intuitive. I can think of several places
>> I would use it. I can't think of a good reason not to include it.
>>
>
> I've yet to see in this thread a use case where list.get() would make
> sense. Specifically, I've yet to see a case where there is straightforward
> duck-typing substitutability between dicts and lists where you'd want that.
>
I've never wanted a `list.get`, but I have occassionally wished that:
1. operator.get/set/delitem were available as builtins (like
get/set/delattr)
2. the builtin getitem accepted an optional "default" argument the way
getattr does
That is, the desired common operation isn't specifically
"obj.get(subscript)" or "obj.get(subscript, default)", it's:
_raise = object()
def getitem(container, subscript, default=_raise):
try:
return container[subscript]
except LookupError:
if default is _raise:
raise
return default
Mappings just happen to already offer that functionality as a method.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
