Questioning the effects of multiple assignment

[Kyle Stanley]

>
> 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?
>

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. Due
to the backwards compatibility issues, I don't think we can realistically
make the default change from a list to a tuple, but that doesn't mean
having a means to explicitly specify that you want the immutability is
unreasonable.

You'd also likely have to argue against why being able to do it during
assignment is advantageous compared to simply doing it immediately after
the initial unpacking assignment. E.g. ::

>>> a, *b, c = 1, 'two', 3, 'four'
>>> b = tuple(b)

(I'd like to particularly emphasize the importance of having some
compelling real-world examples in the proposal if you decide to pursue
this, as otherwise it would likely be dismissed as YAGNI.)


On Tue, Jul 7, 2020 at 8:26 PM dn via Python-list <python-list at python.org>
wrote:

> 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
>