On 03/03/2017 11:01 AM, Sven R. Kunze wrote:
On 03.03.2017 19:29, Ed Kellett wrote:
The reasons already stated boil down to "lists aren't dicts so they shouldn't share
methods", which seems ill-advised
at best, and "I wouldn't use this".
I wonder if those arguing against it also think dicts should not have item
access:
dicts don't have item access -- they have key access. :wink:
a[0]
dict or list? Why should it matter?
Because they are different data types with different purposes.
- Which of the existing things (slice + [default], conditional on a slice,
conditional on a len() call) do you think
is the obvious way to do it?
None of them are. Try/except is the most obvious way. But it's tedious.
[my_value] = some_list[offset:offset+1] or [default_value]
No, it's not terribly pretty, but accessing invalid locations on a list on
purpose shouldn't be that common.
- Are there any examples where list.get would be applicable and not the
obviously best way to do it?
I don't think so. I already have given many examples/ideas of when I would love
to have had this ability. Let me
re-state those and more:
- refactoring (dicts <-> lists and their comprehension counterparts)
dict and list comprehensions are not the same, and adding .get to list won't
make them the same.
- easier to teach
Having `print` be a statement instead of a function made it easier to teach but
that didn't make it a good idea.
For me to think (list/tuple).get() was needed would be if lots of folk either cast their lists to dicts or made their
own list-dict class to solve that problem.
--
~Ethan~
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
