<font face="Courier, Monospaced"><DISCLAIMER></font><br><font face="Courier, Monospaced">i'm not going to defend and fight for this idea too much. i only bring<br>it up because it bothers me. i'm sure some people here would kill me for
<br>even suggesting this, and i really don't want to be killed right now,<br>so i bring it up as something you should think about. nothing more.<br></DISCLAIMER><br><br><NOTE><br>PEP-225 has some weird ideas which may or may not be related to this, but i don't understand how this magical ~ operator can do everything from tuple flattening to list arithmetics, replacing map(), changing the order of operations, deep-copying, list comprehension, rich comparison, and whatever not. so i don't consider this a serious PEP. looks more like an april fool's joke to me, and it seems those japanese celebrate it on september for some reason.
<br></NOTE><br><br></font><font face="Courier, Monospaced">[reposted from comp.lang.python]</font><br><font face="Courier, Monospaced"><br>as we all know, * (asterisk) can be used to "inline" or "flatten" a
<br> tuple into an argument list,
i.e.: <br> </font><p><font face="Courier, Monospaced">def f(a, b, c): <br> ... <br> x = (1,2,3) <br> f(*x) <br> </font></p><p><font face="Courier, Monospaced">so... mainly for symmetry's sake, why not make a "flattening" operator
<br> that also works outside the context of function calls? for example: <br> </font></p><p><font face="Courier, Monospaced">a = (1,2,3) <br> b = (4,5) <br> c = (*a, *b) # ==> (1,2,3,4,5) <br> </font>
</p><p><font face="Courier, Monospaced">yeah, a + b would also give you the same result, but it could be used <br> like format-strings, for "templating" tuples, i.e. <br> </font></p><p><font face="Courier, Monospaced">
c = (*a, 7, 8, *b) <br> </font></p><p><font face="Courier, Monospaced">i used to have a concrete use-case for this feature some time ago, but <br> i can't recall it now. sorry. still, the main argument is symmetry:
<br> it's a syntactic sugar, but it can be useful sometimes, so why limit it <br> to function calls only? <br> </font></p><p><font face="Courier, Monospaced">allowing it to be a generic operator would make things like this
<br> possible: <br> </font></p><p><font face="Courier, Monospaced">f(*args, 7) # an implied last argument, 7, is always passed to the <br> function <br> </font></p><p><font face="Courier, Monospaced">
today you have to do <br> </font></p><p><font face="Courier, Monospaced">f(*(args + (7,))) <br> </font></p><p><font face="Courier, Monospaced">which is quite ugly. <br> </font></p><p>
<font face="Courier, Monospaced">and if you have to sequences, one being a list and the other being a <br> tuple, e.g. <br> x = [1,2] <br> y = (3,4) <br> </font></p><p><font face="Courier, Monospaced">
you can't just x+y them. in order to concat them you'd have to use <br> "casting" like <br> f(*(tuple(x) + y)) <br> </font></p><p><font face="Courier, Monospaced">instead of <br> f(*x, *y) <br>
</font></p><p><font face="Courier, Monospaced">isn't the latter more elegant? <br> </font></p><p><font face="Courier, Monospaced">just an idea. i'm sure people could come up with more creative
<br> use-cases of a standard "flattening operator". but even without the<br> creative use cases -- isn't symmetry strong enough an argument? why are <br> function calls more important than regular expressions?
<br>
</font></p><p><font face="Courier, Monospaced">and the zen supports my point: <br> (*) Beautiful is better than ugly --> f(*(args + (7,))) is ugly <br> (*) Flat is better than nested --> less parenthesis
<br> (*) Sparse is better than dense --> less noise <br> (*) Readability counts --> again, less noise <br> (*) Special cases aren't special enough to break the rules --> then why <br> are function calls so special to add a unique syntactic sugar for them?
<br> </font></p><p><font face="Courier, Monospaced">the flattening operator would work on any sequence (having __iter__ or <br> __next__), not just tuples and lists. one very useful feature i can <br>
think of is "expanding" generators, i.e.: <br> </font></p><p><font face="Courier, Monospaced">print xrange(10) # ==> xrange(10) <br> print *xrange(10) # ==> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
<br> </font></p><p><font face="Courier, Monospaced">i mean, python already supports this half-way: <br> </font></p><div style="display: block;"><font face="Courier, Monospaced">
>>> def f(*args): <br></font></div><font face="Courier, Monospaced">... print args <br> ... <br> </font><div style="display: block;"><font face="Courier, Monospaced">
>>> f(*xrange(10)) <br></font></div><font face="Courier, Monospaced">(0, 1, 2, 3, 4, 5, 6, 7, 8, 9) <br> </font><p><font face="Courier, Monospaced">so... why can't i just do "print *xrange(10)" directly? defining a
<br> function just to expand a generator? well, i could use <br> list(xrange(10))<br>to expand it, but it's less intuitive. the other way is with list-<br>comprehension,<br>[x for x in xrange(10)]<br>which is just, but isn't *xrange(10) more to-the-point?
<br> </font></p><p><font face="Courier, Monospaced">also, "There should be one-- and preferably only one --obvious way to <br> do it"... so which one? <br> (*) list(xrange(10)) <br> (*) [x for x in xrange(10)]
<br> (*) mylist.extend(xrange(10)) <br> (*) f(*xrange(10)) <br> </font></p><p><font face="Courier, Monospaced">they all expand generators, but which is the preferable way? <br> </font></p><p><font face="Courier, Monospaced">
and imagine this: <br> </font></p><p><font face="Courier, Monospaced">f(*xrange(10), 7) <br> </font></p><p><font face="Courier, Monospaced">this time you can't do *(xrange(10) + (7,)) as generators do not
<br> support addition... you'd have to do *(tuple(xrange(10)) + (7,)) which <br> is getting quite long already. <br> </font></p><p><font face="Courier, Monospaced">so as you can see, there are many inconsistencies between function-call
<br> expressions and regular expressions, that impose artificial limitations <br> on the language. after all, the code is already in there to support the<br> function-call version... all it takes is adding support for regular
<br> expressions.</font></p><font face="Courier, Monospaced">so, what do you think? isn't symmetry worth it?<br><br><br>-tomer<br></font>