[Python-ideas] Allowing breaks in generator expressions by overloading the while keyword

[M.-A. Lemburg]

On 21.02.2014 14:34, Masklinn wrote:
> On 2014-02-21, at 14:03 , M.-A. Lemburg <mal at egenix.com> wrote:
>> On 21.02.2014 13:25, Nick Coghlan wrote:
>>> On 21 February 2014 22:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>> That's not very readable to most Python programmers, but what if you
>>>> could write something like:
>>>>
>>>>    isprime = all(n % p for p in takewhile((: ? ** 2 < n), primes_seen))
>>>>
>>>> This is somewhat similar to the implicit lambda proposal in
>>>> http://legacy.python.org/dev/peps/pep-0312/, but with the following
>>>> two essential differences:
>>>>
>>>> 1. The parentheses would be required (as per generator expressions,
>>>> and as is being discussed for except expressions)
>>>> 2. By using a "?" token within the implicit lambda, you would create a
>>>> lambda that takes a single argument. If there is no such token, then
>>>> it would take no arguments.
>>>
>>> Oh, and under such a proposal, the generator expression:
>>>
>>>    (x for x in seq)
>>>
>>> would be semantically equivalent to:
>>>
>>>    (: yield x for x in ?)(seq)
>>>
>>> Currently, there's no underlying construct you can decompose a
>>> generator expression into, because there's no notation for a lambda
>>> expression with an anonymous parameter.
>>
>> Hmm, this reminds me too much of regular expression syntax :-)
>>
>> I wonder why people are so keen on stuffing too much logic into
>> a single line. Must be a twitter/SMS side-effect.
> 
> "Line" is a red herring, I think. Nobody *really* cares about lines.
> "Expression" is the important factor. Moving stuff out of expressions
> and into separate statements requires finding out a name for the result,
> is generally significantly more verbose and isn't necessarily clearer.

But it helps a lot in debugging the code :-)

Debugging complicated expressions becomes really difficult and
adding a few local variables to put on the watch list helps
a lot.

> Depending on the situation, it may also require significant reworking of
> existing (supposedly working) code.
> 
> I usually write non-trivial generator expressions over multiple lines,
> I may be after them remaining a single (readable) expression depending
> on context.
> 
> Well that's just my experience anyway.
> 
>> Programs don't get faster that way, they don't get more readable,
>> you don't get to do more things that couldn't do otherwise
>> and requiring a master in computer science to be able to understand
>> what goes on in one of those magical lines doesn't feel right
>> to me either, given that we are promoting Python as first
>> programming language.
> 
> Was the MSCS insult really necessary?

Which "insult" ? I have no intention insulting anyone and
apologize if the above was interpreted that way.

I was just referring to the complicated nature of the resulting
expressions and raising a concern that by introducing more constructs
to write such things, we actively support writing Python programs
which are no longer easy to read.

>> Of course, tossing around ideas like these is fun and I don't
>> want to spoil it. Eventually something useful will come out of
>> these discussions, I'm sure :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-02-12: Released mxODBC.Connect 2.0.4 ...     http://egenix.com/go53

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/