Questioning the effects of multiple assignment
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
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
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
(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
(in themselves a frequent 'gotcha' for newcomers, but once understood,
make perfect sense and realise powerful opportunities)
Python:2, those others:nil - still!
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
(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?