determining the number of output arguments

[Josiah Carlson]

aleaxit at yahoo.com (Alex Martelli) wrote:
> 
> Fernando Perez <fperez528 at yahoo.com> wrote:
> 
> > > Yep, that's the cookbook recipe Jp was mentioning -- Sami Hangaslammi's
> > > recipe 284742, to be precise.  Yep, it _is_ going into the printed 2nd
> > > edition (which I'm supposed to be working on right now -- deadline
> > > closing in, help, help!-).
> > 
> > Well, I feel pretty good now: I didn't see Jp's mention of this, and just
> > guessed it should be doable with those three tools.  I just looked it up, and
> > it seems it's exactly what I had in mind :)  Cute hack, but I tend to agree
> > with Scott Daniels' comment that this kind of cleverness tends to promote
> > rather unreadable code.  Maybe I just haven't seen a good use for it, but I
> > think I'd rather stick with more explicit mechanisms than this.
> 
> Yeah, but "once and only once" is a great principle of programming.  Any
> time you have to say something _TWICE_ there's something wrong going on.
> 
> So,
> 
> a, b, c, d = lotsa[:4]
> 
> _should_ properly give the impression of a code smell, if your "once and
> only once" sense is finely tuned.  What's the business of that ':4' on
> the RHS?  Showing the compiler that you can count correctly?!  You're
> having to tell twice that you're getting four items into separate
> variables, once by listing exactly four variables on the LHS, and
> another time by that ':4' on the RHS.  IMHO, that's just as bogus as
> struct.unpack's limitation of not having any way to indicate explicitly
> 'and all the rest of the bytes goes here', and for similar reasons.

The slicing on the right is not so much to show the compiler that you
know how to count, it is to show the runtime that you are looking for
a specified slice of lotsa.  How would you like the following two cases
to be handled by your desired Python, and how would that make more sense
than what is done now?

a,b,c = [1,2,3,4]
a,b,c = [1,2]


> I think it would be better to have a way to say 'and all the rest'.
> Lacking that, some automated way to count how many items are being
> unpacked on the LHS is probably second-best.

Is it worth a keyword, or would a sys.getframe()/bytecode hack be
sufficient? In the latter case, I'm sure you could come up with such a
mechanism, and when done, maybe you want to offer it up as a recipe in
the cookbook *wink*.


> Another case where a specific number of items is requested, which is not
> (syntactically speaking) a multiple assignment, is assignment to an
> _extended_ slice of, e.g., a list (only; assignment to a slice with a
> stride of 1 is happy with getting whatever number of items are coming).
> I don't particularly LIKE writing:
>     L[x:y:z] = len(L[x:y:z]) * [foo]


I much prefer...

for i in xrange(x, y, z):
    L[i] = foo

But then again, I don't much like extended list slicing (I generally
only use the L[:y], L[x:] and L[x:y]  versions).

 - Josiah