*-unpacking

[Alex Martelli]

David Mertz wrote:

> Alex Martelli <aleax at aleax.it> wrote previously:
> |Nope.  We're discussing situations where ONE pop from the start is
> |needed; and you claimed I knew that in that case reversing the list
> |and popping from the end was faster.
> 
> Nah. I believe the context of my first note in the thread made the
> imagined situation obvious.  The situation Greg described was where you
> want to look (from the left) at one item at a time, then decide
> whether/when to grab the next based on that one.

He was describing a commandverb / args separation.  _One_ commandverb,
zero or more args to go with it.

> That one-at-a-time-but-many-times seems to me the case where
> 'car,*cdr=thelist' is most useful.  And for that, one-reverse-
> plus-many-pops is the best current approach.

If you have a mapping from command-verb to number of req arguments
(with all further optional args to be left as the sequence), I
think slicing is in fact clearer:

    command_verb = args[0]
    num_req_args = numargs.get(command_verb, 0)
    requiredargs = args[1:1+num_req_args]
    other_args   = args[1+num_req_args:]

I don't think any unpacking or popping, with or without reversing
thrown in, can compete with this clarity.

In most other use cases where it might initially seems that the
best idea is "consuming" the sequence (and thus that reversing
might be a clever idea), it turns out that just *iterating* on
the sequence (or an iter(...) thereof, to keep iteration state)
is in fact quite preferable.


> I quite concur with Alex that a '.reverse()' is not particularly
> worthwhile to do just one '.pop()' (I guess it turned out to save a
> couple milliseconds, but nothing important).  The hermeneutics of the

_micro_seconds (for lists of several thousands of items).

> thread aren't worth getting hung up on.

If you have no grounds to claim I made a mistake, then please don't
(and apologize if you think you have done so in error).  If you do 
think you can prove it, and I disagree, then it seems to me that
this disagreement IS "worth getting hung up on".


> Of course, in Greg's case of parsing a dozen command-line switches, the
> speed issue is not interesting.  The whole '.reverse()' thing only
> matters when you need to handle thousands of items (and *that*, I think,
> Alex will admit he knows :-)).

I do know (having read Knuth) that micro-optimizations should be ignored
perhaps 97% of the time, and can well guess that this case doesn't look
anywhere close to the remaining "perhaps 3%".  I.e., that (like most
debates on performance) this one has little substance or interest.

Much more interesting might be to give the list.reverse method optional
start and end parameters to reverse in-place a contiguous slice of a
list -- the current alternative:
    aux = somelist[start:end]
    aux.reverse()
    somelist[start:end] = aux
is just too sucky, substantially diminishing the interest of the
reverse method.  But that, of course, is a totally unrelated subject.


Alex