[Python-Dev] Re: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions (original) (raw)

Tim Peters tim_one@email.msn.com
Wed, 16 Aug 2000 00:13:00 -0400

[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 . 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 ).

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.