On Fri, 3 Mar 2017 at 17:03 Ethan Furman <et...@stoneleaf.us> wrote: > On 03/03/2017 08:09 AM, Ed Kellett wrote: > > > P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO > solve) this problem doesn't mean it should supersede > > this discussion. > > The advantage of PEP 463 is that issues like this would be less pressing, > and it's much more general purpose. >
PEP 463 won't solve this problem for me because its solution is as ugly as the thing it's replacing. Conceptually, I'd even argue that it's uglier. Also, if you want a general-purpose solution to everything, propose with-expressions, but that's another discussion. The existence of general-purpose things doesn't mean specific issues aren't worth talking about. > Personally, I don't think `get` belongs on list/tuple for reasons already > stated. > 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'm not convinced that the latter is generally true; I've often looked for something like a list.get, been frustrated, and used one (chosen pretty much at random) of the ugly hacks presented in this thread. I'd be surprised if I'm the only one. I guess I don't have any hope of convincing people who think there's no need to ever do this, but I have a couple of questions for the people who think the existing solutions are fine: - 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? - Are there any examples where list.get would be applicable and not the obviously best way to do it? Ed
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
