[Tim] >> Because Guido hates it. It's almost certainly an error on the part >> of the user [Greg Ewing] > Guido doesn't like it, therefore it must be an error. Great > piece of logic there. Perhaps I should have used a colon: Guido hates it *because* it's almost certainly an error. I expect the meaning was plain enough without that, though. >> Catching likely errors is a benefit for the user. > What evidence is there that this particular "likely error" is Nobody said it was likely. Scare quotes don't work unless you quote something that was actually said <wink>. Likeliness has nothing to do with whether Python calls something an error anyway, here or anywhere else. > going to be prevalent enough to justify outlawing a potentially > useful construct? Making a list that's either empty or a singleton is useful? Fine, here you go: (boolean and [x] or []) We don't need listcomps for that. listcomps are a concrete implementation of mathematical set-builder notation, and without iterators to supply a universe of elements to build *on*, it may make *accidental* sense thanks to this particular implementation -- but about as much *logical* sense as map(None, seq1, seq2, ...) makes now. SETL is the original computer language home for comprehensions (both set and list), and got this part right (IMO; Guido just hates it for his own incrutable reasons <wink>). > Where are the hoardes of Haskell user falling into this trap and > clamouring for it to be disallowed? I'd look over on comp.lang.haskell -- provided anyone is still hanging out there. >> really the same reason that zip() without arguments raises an >> exception. > No, I don't think it's the same reason. It's not clear what > zip() without arguments should return. There's no such difficulty > in this case. A zip with no arguments has no universe to zip over; a listcomp without iterators has no universe to build on. I personally don't want syntax that's both a floor wax and a dessert topping. The *intent* here is to supply a flexible and highly expressive way to build lists out of other sequences; no other sequences, use something else. > For the most part, Python is free of artificial restrictions, and I > like it that way. Imposing a restriction of this sort seems > un-Pythonic. > > This is the second gratuitous change that's been made to my > LC syntax without any apparent debate. The syntax hasn't been changed yet -- this *is* the debate. I won't say any more about it, let's hear what others think. As to being upset over changes to your syntax, I offered you ownership of the PEP the instant it was dumped on me (26-Jul), but didn't hear back. Perhaps you didn't get the email. BTW, what was the other gratuitous change? Requiring parens around tuple targets? That was discussed here too, but the debate was brief as consensus seemed clearly to favor requiring them. That, plus Guido suggested it at a PythonLabs mtg, and agreement was unanimous on that point. Or are you talking about some other change (I can't recall any other one)? > While I acknowledge the right of the BDFL to do this, I'm starting > to feel a bit left out... Well, Jeez, Greg -- Skip took over the patch, Ping made changes to it after, I got stuck with the PEP and the Python-Dev rah-rah stuff, and you just sit back and snipe. That's fine, you're entitled, but if you choose not to do the work anymore, you took yourself out of the loop. >> I realize that Haskell does allow it -- although that would be a >> surprise to most Haskell users > Which suggests that they don't trip over this feature very > often, otherwise they'd soon find out about it! While also suggesting it's useless to allow it.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4