git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
>     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!
> 
> 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 
asking, "why?"!

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...)
-- 
Regards =dn