On Sat, 07 Oct 2006 18:06:47 -0700, MonkeeSage wrote: > On Oct 7, 7:59 pm, Steven D'Aprano > <[EMAIL PROTECTED]> wrote: >> Because they aren't needed often, and when they are, they are easy to >> implement? > > More often and easier to implement than dict.has_key / get?
No, *less* often. That's the point -- it is fairly common for people to want dictionary lookup to return a default value, but quite rare for them to want sequence lookup to return a default value. A sequence with a default value would be, in some sense, equivalent to an infinite list: [A, B, ... , Z, default, default, default, ... ] where the A...Z are actual values. (Obviously you don't actually have an infinite list.) I can't think of any practical use for such a thing; the only thing that comes close is in some Cellular Automata it is sometimes useful to imagine cells out of range to be always in some default state. But generally speaking, you don't implement Cellular Automata with lists. >> It is hard to see where list.get(index, default) would be useful, since >> accessing an index out of range of a list is generally an error, unlike >> accessing a missing key. > > Uh, no. KeyError. dict.get() doesn't raise KeyError. That's the whole point of get(), it returns a default value instead of raising KeyError. >> Not every piece of functionality needs to be a built-in. > > Agreed. but why implement a certain functionality in one place but leave > it out of another? Because implementation requires time and effort. It makes the regression tests more complicated and bloats the code base. If the feature doesn't scratch anybody's itch, if there isn't a clear use for it, it won't be implemented. If you don't care enough to even make a formal feature request, let alone a PEP, then why should people who care even less actually write the code? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list