Generating a random subsequence

[Steve Holden]

"Justin Sheehy" <justin at iago.org> wrote in message
news:mailman.1010611097.9582.python-list at python.org...
> Tom Bryan <tbryan at python.net> writes:
>
> > Is that just true of +=?
> >
> > That is, if returnSeq is a list then, I can say
> > returnSeq = returnSeq + item
> > OR
> > returnSeq.append( item )
> > OR
> > returnSeq += item
> >
> > You're saying that the last one is roughly equivalent to the second one
and
> > not the first?  Or are they all three equivalent?
> >
> > the-last-time-I-used-python-there-wasn't-a-+=-ly,
>
> The behavior of all of the augmented assignment operators depends on
> the presence of a special method in the left operand.  If the special
> method is not present, they are roughly equivalent to 'a = a OP b".
>
> IMO, the definition of those methods for some of the builtin data
> structures (e.g. lists) were poorly chosen.
>
> note: It is not the behavior of the operator that I take issue with.
>       It is the behavior of the method exposed to that operator by
>       certain datatypes.
>
> A trivial example that illustrates how the definitions of these
> methods causes Python to badly violate the principle of least surprise
> when used by someone who knew Python pre-augassign and now knows that
> a "+=" operator exists:
>
> def augassign(seq1, seq2):
>     seq1 += seq2
>     return seq1
>
> >>> rhs = (4,)
> >>> a = (1, 2, 3)
> >>> b = [1, 2, 3]
> >>> augassign(a, rhs)
> (1, 2, 3, 4)
> >>> a
> (1, 2, 3)
> >>> augassign(b, rhs)
> [1, 2, 3, 4]
> >>> b
> [1, 2, 3, 4]
>
> Many assumptions that I am used to with Python are not valid with
> regard to that last line.  If I had not been explicitly educated about
> the behavior of += and friends, I would definitely not expect the
> sequence referred to by a or b here to (maybe) be mutated by the
> function call.
>
> I believe that giving lists this behavior was a serious mistake.
> Using this new behavior makes sense for user-defined classes and some
> interesting data structures such as matrices, but this disparity in
> results between the basic sequence types is very unfortunate.
>
> This may gain some efficiency in reducing the number of list
> allocation, but I don't think that the confusion is worth it.
>
> A small implementation detail, a real step away from Programming for
Everybody.
>
Justin:

Fortunately or unfortunately this topic was exhausted over a year ago. I
remember arguing until I was blue in the face that different semantics for

    a = a op b

and

    a op= b

were counterintuitive and likely to lead to newbie confusion. The real
sticking point appeared to me to be the differences between mutable and
immutable objects, plus the fact that mutable objects were free to implement
in-place modification or not, as the implementor chose.

Eventually Guido silenced my protests by pointing out that the feature need
had been decided long ago, and that the proposed change was therefore
implementing semantics which had been decreed to be necessary, or at least
desirable, before I ever raised my head over the parapet. Truth to tell, I'm
no longer so convinced that the subtleties will be hard to explain to
beginners.

More briefly: you may well be right, but you are going to have to learn to
live with it, and most people won't regard it as a wart.

unlike-print->>-which-also-stays-in-ly y'rs -  steve
--
http://www.holdenweb.com/