[Python-3000] Using *a for packing in lists and other places

Sun Mar 16 02:06:51 CET 2008

-1.
While the syntax has a basic beauty, it requires too much odd explanation.
"*" and "**" are already binary operators.
The '*' unary operator can confuse migrating programmers already.
It makes puzzles too easy, e.g., yield **[2**3*i, for i in range(2*3**4)]
On Sat, Mar 15, 2008 at 6:55 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 06:33 PM 3/15/2008 -0500, Michael Urman wrote:
> > > > I'm not sure how to solve this except by adopting a different syntax
> > > > for the multiple-yield. Perhaps
> > > >
> > > > *yield x
> > >
> > > If there really were an inconsistency here, I would certainly not suggest
> > > fixing it that way, yuuueghh.
> >
> >Agreed about *yield looking yucky. In a previous thread somewhere
> >around http://mail.python.org/pipermail/python-dev/2006-January/059955.html
> >a construct like "yield from x" was offered. It certainly helps
> >clarify the difference between iteratively yielding the values from
> >another iterator and yielding the values of an iterator as a tuple.
> >While parsing rules do differentiate, I don't find the behavior
> >obvious, and expect the differences between
> > yield *x; yield *x(); yield *x,; yield (*x,); and yield *(x,)
> >would become one of python's warts in a few years, if adopted.
>> After following this thread for a bit, I think it's a wart
> already. :) The potential for confusion with the other *assign
> target idea is too high.
>> I don't have a problem with "item for *item,val in blah", but "*item
> for item in blah" makes my head hurt. Why not just say "i2 for i1 in
> blah for i2 in i1"? Yes, it's a bit more verbose, but not frequent
> enough to justify the *, and you can tell what's going on by
> textually transposing to the nested for loops. Plus, it works for
> any depth. What are you going to do if it's triple-nested? Use
> **? What about ***? Where does it end?
>> So I think "yield *" and "*item for item in..." are broken for the
> same reason. In the function call use case, and in simple
> assignment, it is treated as a literal quasi-textual
> expansion. However, such an expansion in the yield case would yield
> a tuple, and the literal expansion in the comprehension case would
> make no sense. (If done by true textual substitution, it would have
> to be a syntax error.)
>> And I think that a quasi-textual substitution is the right mental
> model for * expressions, as it's simple to explain and easy to reason
> out what happens.
>>>> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>