determining the number of output arguments

[Alex Martelli]

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.

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.
 
> Anyway, is it true that this will only work for non-extension code?  If
> you are being called from a C extension, dis & friends are toast, no?

Yep, whenever your function isn't being called as the only item on the
RHS of a multiple assignment, then counting how many items are on the
LHS are being unpacked in that inexistent or unapplicable multiple
assignment is right out.  Presumably, any way to count the number of
items in this fashion will need a way to indicate "not applicable",
though it's not obvious whether raising an exception, or returning a
clearly bogus value such as 0, is most useful.

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.e. having to extract the extended slice first, on the RHS, just to
gauge how many times I must repeat foo.  However, if I squint in just
the right way, I _can_ try to convince myself that this _isn't_ really
violating "once and only once"... and I do understand how hard it would
be to allow a 'how many items are needed' function to cover this
case:-(.


Alex