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

[Tim Peters]

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