Questioning the effects of multiple assignment

[dn]

On 7/07/20 7:44 PM, Kyle Stanley wrote:
>     Can you explain why these two (apparently) logical assignment processes
>     have been designed to realise different result-objects? 
> 
> 
> The reason is because of the conventions chosen in PEP 3132, which 
> implemented the feature in the first place. It was considered to return 
> a tuple for the consistency w/ *args that you initially expected, but 
> the author offered the following reasoning:
> 
>  > Make the starred target a tuple instead of a list. This would be 
> consistent with a function's *args, but make further processing of the 
> result harder.
> 
> So, it was essentially a practicality > purity situation, where it was 
> considered to be more useful to be able to easily transform the result 
> rather than being consistent with *args. If it resulted in a tuple, it 
> would be immutable; this IMO makes sense for *args, but not necessarily 
> for * unpacking in assignments. The syntax is highly similar, but they 
> are used for rather different purposes. That being said, I can certainly 
> understand how the behavior is surprising at first.
> 
> There's a bit more details in the mailing list discussion that started 
> the PEP, see 
> https://mail.python.org/pipermail/python-3000/2007-May/007300.html.


Thank you - I had failed to find that discussion, but it and the 
explanation above, make perfect sense.


You can color me hobgoblin for expecting ?'consistency'! - and whilst 
I'm liberally (mis-)quoting: I'm not going to argue with the better 
minds of the giants, upon whose shoulders I stand...


Continuing on, but instead of considering the handling of 
argument/parameters to be 'authoritative' (which we were, from the 
perspective of 'consistency'); perhaps consider the assignment decision 
as "authoritative" and consider if the calling-behavior should be made 
consistent:-


One of the features of Python's sub-routines, which I enjoy, is 
summarised in two ways:

1 the many books on 'programming style' (for other languages) which talk 
about a function's signature needing to separate 'input-parameters', 
from 'output-parameters' to enhance readability.
- in Python we have parameters (let's say: only for input), neatly 
separated from 'output' values which don't get-a-mention until the 
return statement
(see also "typing" - although the "return" might be considerably 
separated from the "->").
Python:1, those others:nil!

2 a perennial-question is: "are Python's function-arguments passed 
by-reference, passed by-value, or what?"
- in Python we pass by assignment and 'the rules' vary according to 
mutability.
(in themselves a frequent 'gotcha' for newcomers, but once understood, 
make perfect sense and realise powerful opportunities)
Python:2, those others:nil - still!
(IMHO)

A matter of style, which I like to follow [is it TDD's influence? - or 
does it actually come-from reading about DBC (Design by Contract*)?] is 
the injunction that one *not* vary the value of a parameter inside a 
method/function.
(useful in 'open-box testing' to check both the API and that 
input+process agrees with the expected and actual output, but irrelevant 
for 'closed-box testing')
This also has the effect of side-stepping any unintended issues caused 
by changing the values of mutable parameters!
(although sometimes it's a equally-good idea to do-so!)

Accordingly, binding argument-values to mutable parameters (instead of 
an immutable tuple) might cause problems/"side-effects", were those 
parameters' values changed within the function!


Making sense to you?
-- 
Regards =dn