[Tutor] update a list

dn PyTutor at DancesWithMice.info
Sun Oct 11 16:28:58 EDT 2020


On 12/10/2020 05:21, alexkleider via Tutor wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, October 11, 2020 4:17 AM, Alan Gauld via Tutor <tutor at python.org> wrote:
> 
>> On 11/10/2020 11:18, dn via Tutor wrote:
>>
>>> On 11/10/2020 21:44, Manprit Singh wrote:
>>>
>>>> Dear sir ,
>>>> Consider a problem where I have to update a list , at even places with
>>>> increment of 1 and at odd places with increment of 2 . Just need to check
>>>> if this can be done in a better way. My solution is given below:
>>
>>> Remember that you can slice a sequence. Thus, a faster solution is:
>>>
>>>>>> l = [2, 3, 5, 7, 6, 4]
>>>>>> new_l = list()
>>>>>> for index in range( 0, len( l ), 2 ):
>>>>>> ... new_l.append( l[ index ] + 1 )
>>>>>> ... new_l.append( l[ index + 1 ] + 2 )
>>>>>> ...
>>>>
>>>>>> new_l
>>>>>> [3, 5, 6, 9, 7, 6]
> 
> The above solution breaks down if the length of the list happens to be odd:
> Python 3.7.3 (default, Jul 25 2020, 13:03:44)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>>>> m = [2, 3, 5, 7, 6, 4, 9]
>>>> new = list()
>>>> for index in range(0, len(m), 2):
> ...   new_m.append(m[index] + 1)
> ...   new_m.append(m[index + 1] + 1)
> ...
> Traceback (most recent call last):
>    File "<stdin>", line 3, in <module>
> IndexError: list index out of range

That's absolutely true, (and continuing-on from my additional question 
of the OP) illustrates the tyranny of such abstract and artificial problems!
- and why I won't use them as examples/assignments in my own training 
materials!

That said, and some of my objection, if there are to be 'rules' 
("specifications") then they must be stated up-front. If they are 
'hidden', then the error is not ours, as coders! (but we would not 
'escape' responsibility for such). In academe there are some who choose 
to set 'trick questions', but this seems to lead to a 'them and us' 
relationship, rather than a team approach.

To determine if the assumption that index+1 could exist (that the list 
is always of zero or even length is "wrong"), requires access to the 
user/client, or to observations in 'the real world'. On the one hand, it 
is a reasonable assumption because the problem appears to assume pairs. 
On the other hand, 'we are not told this' - again, an assumption: that 
we would be told 'everything' for this version of 'true'. Anyone who has 
dealt with user-specifications knows that such assumptions are dangerous 
(both ways)!

At this point, we can widen the discussion into team management, SCRUM, 
user involvement in dev.teams, etc, etc - but this is Python list, so I 
shall (attempt to) rein-in my enthusiasm!


Is it our responsibility, as coders, to notice these assumptions/risks, 
and to bring them to the client's attention in seeking clarification?

Does 'academic purity' allow such, ie how appropriate are school-room 
rules, such as 'use your own intelligence/initiative', 'don't copy', 
'don't talk to others'?

If I don't know the target, how can I meet the requirements (except by 
luck). If I don't know the rules/assumptions, how can I 'defend' my 
decisions? If we (client and coder) aren't on the same course, is 
unhappiness inevitable?

Why do I avoid such? Because my objective is to prepare trainees to work 
in 'the real world'. Thus, imagine a situation where I had spent 
weeks/months preparing some solution, all by myself and without 
'bothering' anyone else. Then you/my boss/client come-along and say 
"but...". Both feeling disappointment, an highly-charged, even 
emotional, argument might ensue. At the very least, someone has to pay 
for my time, and thus lose/waste money. Surely that's something to avoid?


Now, to evoke a (sardonic) chuckle: re-read the above and spot the 
inherent assumption...


Back to Python: In 'the real world', we do occasionally have need to 
take data 'two by two'/in-pairs - not often, but it does occur. As an 
example, consider PyGame which has functions to place visual objects on 
its "canvas" (the screen). The four arguments are:
- an x,y pair, ie Cartesian Coordinates, and
- a w,h pair representing the rectangular dimensions of the object
(width and height).

In this scenario, whilst we could consider the data as a sequence of 
four, or two sequences of two; if there are any geometric calculations 
to be performed, it is (in my experience) easier to code the first pair 
as an object which can, at different times, either be processed as a 
unit or split into x,y-scalars, as required within the application, ie 
Cartesian Coordinates. Similarly the second pair could be treated as a 
Vector, according to the full specification of needs.

Accordingly, the rather academic approach, extracting pairs from a 
generic list structure, as outlined in the original post, doesn't see 
the light of day - it is not possible to have 2-D dimensions without a 
'pair', nor 2-D Cartesian Coordinates.


However, and to address the (quite reasonable) criticism: to deal with 
an 'incomplete' list of pairs, in a thoroughly 'pythonic' fashion, wrap 
access to the second of each 'pair', with try...except.

NB Such a concern is inherently-avoided in the OP's original solution!
-- 
Regards =dn


More information about the Tutor mailing list