[Python-ideas] get() method for list and tuples

David Mertz mertz at gnosis.cx
Sun Mar 5 14:54:12 EST 2017


On Sun, Mar 5, 2017 at 11:22 AM, Ed Kellett <edk141 at gmail.com> wrote:

> On Sun, 5 Mar 2017 at 18:13 David Mertz <mertz at gnosis.cx> wrote:
>
>>     data = args.get(17, "<empty>")
>>
>> Then I'm pretty sure the programmer thinks she's being passed a very
>> different type of collection than is actually available.  I'd rather that
>> fails right away and in an obvious way then silently produce a value.
>> Specifically, if I think I'm dealing with a list that is likely to have 20
>> items (rather than maybe 4 or fewer), I'm almost sure the best way to deal
>> with it is in a loop (or comprehension, map(), etc) and NOT by poking into
>> large index positions that may or may not be present.
>>
>

> That's up to the programmer. args[17] exists and does fail immediately. If
> the programmer provides a default value, presumably they know they want one.
>

In terms of an actual use case, I can see it for "Lists no longer than 4".
Any other use of this hypothetical method would be an anti-pattern and be a
bad habit.  Yes, programmers can do what they want, but providing a method
is a hint to users (especially beginners, but not only) that that is the
"right way" to do it.


> I really think that depends what it's a list of. If the positions of
> things in the list are important (as with an argument parser, or perhaps a
> lookup table) I fail to see why it would be wrong to peek.
>

But the positions NEVER are important when you get to a 20 item list.  If
you design an argument parser that is looking for "the 17th argument" you
are doing it wrong.  I'm not saying that's impossible (nor even hard) to
program, but it's not good practice.

Sure, I'm happy to take 20+ arguments, especially if they result from a
glob pattern used at the command line, naming files.  But when I'm doing
that, I want to deal with those filenames in a loop, handling each one as
necessary.  In that pattern, I *never* want exactly 20 arguments, but
rather "however many things there are to handle."


> If lists were really designed to be used only as you and some others in
> this thread are suggesting, I don't think they'd have indexed access at all.
>

Actually, when I teach I make a big point of telling students (for me,
professional scientists and programmers who have used other PLs) that if
they are indexing a list they should look again and question whether that's
the right pattern.  Of course there are times when it's needed, but they
are fewer than C, Java, or Fortran programmers think.

If this method existed, I'd want it implemented roughly like this:

In [1]: class GetList(list):
   ...:     def get(self, i, default=None):
   ...:         if i > 4:
   ...:             raise NotImplemented("You should NOT use this method
for long lists!")
   ...:         try:
   ...:             return self[i]
   ...:         except IndexError:
   ...:             return default
   ...:

In [2]: l = GetList(['err','my message'])

In [3]: l.get(1, 'no message')
Out[3]: 'my message'

In [4]: l.get(2, 'no details')
Out[4]: 'no details'

In [5]: l.get(10, 'some data')
---------------------------------------------------------------------
TypeError                           Traceback (most recent call last)
<ipython-input-5-3306fdc8b5a0> in <module>()
----> 1 l.get(10, 'some data')

<ipython-input-1-441d5e3eda9f> in get(self, i, default)
      2     def get(self, i, default=None):
      3         if i > 4:
----> 4             raise NotImplemented("You should NOT use this method
for long lists!")
      5         try:
      6             return self[i]

TypeError: 'NotImplementedType' object is not callable


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170305/82b86604/attachment.html>


More information about the Python-ideas mailing list