On Sat, Mar 15, 2008 at 6:01 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On Sat, Mar 15, 2008 at 3:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > This post does point out an inconistency in Thomas's patch: > > > > def f(): > > yield 1, 2, 3 > > > > Yields a single three-tuple. > > > > But > > > > def f(): > > yield *[1, 2], 3 > > > > Yields three separate values. > > Uhm, what? It doesn't, and it shouldn't, and I'm not sure what makes you > think it does.
Sorry, I misread the output. I *expected* it to do this based on an incomplete understanding of what you've implemented. Since I made this mistake, I expect others will too; I think *something* needs to change. A strict proposal would be to change the syntax of yield so that it only accepts a single expression, optionally prefixed with a '*'. This would render yield 1, 2, 3 illegal -- you'd have to rewrite this as yield (1, 2, 3) That's a minor inconvenience and can be taken care of by 2to3 easily. A less strict proposal would be to allow yield *expr and yield expr, expr, ... but not yield *expr, expr, ... nor yield expr, *expr, ... # etc. While we discussed this over drinks last night, it also made me think about the end-case of *expr in other contexts. We have the following series of similar assignments: a, b, *c = x b, *c = x *c = x # disallowed *c, = x # use this instead This is defensible by analogy to the following: a, b, c = x # unpack 3-tuple b, c = x # unpack 2-tuple c = x # not a tuple unpacking! c, = x # must unpack 1-tuple this way However while in the latter case "c = x" there is no syntactic hint that a tuple might be intended, one could say that in "*c = x" the star is plenty enough of a hint. (The semantics would be clear by taking the limit of the first series of examples; "*c = x" is equivalent to "c = list(x)".) I don't think I actually *like* this; it would make "yield *expr" even more of an exception, and it doesn't have any attractive use cases. However I believe that the analogy between regular tuple unpacking and extended tuple unpacking is a relatively weak argument to forbid "*c = x", and I expect that this gray area is likely to cause users to trip up in their understanding of this proposed new syntax; especially if they think too hard about it. :) Two other comments on Thomas's proposal: (a) *if* we're going to do this, it should also be done for function calls (though not for function defs). I'd like all of these to be legal (and their interpretation is obvious): f(a, b, *x, k=val) f(a, *x, b, k=val) f(*x, a, b, k=val, **kw=stuff) (b) I noticed that the following are equivalent: a, *b a, (*b) I think the latter should not be allowed; the * should be present at the same level as the commas to which it belongs. (This may be an issue for the existing extended tuple unpacking as well?) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
