Questioning the effects of multiple assignment
On 8/07/20 2:40 PM, Kyle Stanley wrote:
> 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
> 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!
> I think I can see where you're going with this, and it makes me wonder
> if it might be a reasonable idea to have an explicit syntax to be able
> to change the behavior to store those values in a tuple instead of a
> list. The programming style of making use of immutability as much as
> possible to avoid side effects is quite common, and becoming
> increasingly so from what I've seen of recent programming trends.
> If something along those lines is something you'd be interested in and
> have some real-world examples of where it could specifically be useful
> (I currently don't), it might be worth pursuing further on python-ideas.
Thanks for this.
Nor can I imagine a strong reason to vary the existing implementation,
and have no real-world example to offer which might drive such motivation.
Our surprise was an apparent lack of consistency. However, the
explanation makes good sense (IMHO - now that it is properly informed).
As you said, practicality trumps consistency. So, the two situations
each have their own rule - and Python is better understood! The value of
Contrary to many, I enjoy it when someone pushes me into a 'corner' that
I can't explain - such represents both a challenge and learning
opportunity, and probably useful that the Junior Programmer-concerned
should appreciate that no-one knows 'everything'.
(hopefully, others 'playing along at home' using the summary of our
REPL-experimentation, have also learned - without first feeling as
flummoxed, as we were...)