On 21 February 2014 23:03, M.-A. Lemburg <mal@egenix.com> wrote:
On 21.02.2014 13:25, Nick Coghlan wrote:
On 21 February 2014 22:18, Nick Coghlan <ncoghlan@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.
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.
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 :-)
The reason I keep beating my head against this particular wall (cf. PEP 403's @in clauses and PEP 3150's given suites) is that my personal goal for Python is that it should be a tool that lets people express what they are thinking clearly and relatively concisely. As far as I have been able to tell, the persistent requests for "multi-line lambdas", cleaner lambda syntax, etc, are because Python doesn't currently make it easy to express a lot of operations that involve higher order manipulation of "one shot" callables - closures or custom functions where you *don't* want to re-use them, but Python still forces you to pull them out and name them. I think PEP 403 is my best current description of the mental speed bump involved: http://www.python.org/dev/peps/pep-0403/ Decorators are an example where this used to be a problem (compounded by other issues related to repeating the name multiple times): def f(cls): ... f = classmethod(f) But this was replaced by the much cleaner: @classmethod def f(cls): ... Like try/except/finally -> with statements, decorators replaced a "bracketed" construct with a "prefix" only construct, greatly improving the readability in the process. Extracting a named one-shot function inline is problematic in much the same way: def custom_key(v): # Helper for a sorted call you don't know is coming yet ... x = sorted(seq, key=custom_key) # Oh, that's what it is for The idea behind both PEP 403 and 3150 is to be able to do a similar bracketed -> prefix only transformation for more constructs where the callable is incidental to the real operation. The PEP 403 approach to custom key functions: @in x = sorted(seq, key=custom_key) def custom_key(v): ... I'm not actually happy with the PEP 403 syntax (or the complexity of PEP 3150), but I think the problem they both attempt to solve is one worth having a better answer for. I just haven't figured out what that answer might look like yet (and neither has anyone else) :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia