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
--
https://mail.python.org/mailman/listinfo/python-list
