Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > > Guido van Rossum wrote: > > But as long as we are describing the > > present state we should call a spade a spade, etc. > > I guess I take a syntactic view of the status quo, because, while > lambdas may be implemented as anonymous functions, the current syntax > doesn't let me *write* an arbitrary function as a lambda. You can write anything as a lambda, but it may not be easy. > Regardless, I believe the balance will eventually tip in some > direction - either lambdas disappear entirely, become able support > full anonymous functions, or else the idea of a 'deferred expression' > becomes a defining characteristic, rather than a syntactic quirk. I would put my money on the latter rather than the former. The moment functions start moving beyond a line or so is when they usually start begging for a name. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Guido van Rossum wrote: > [Nick Coghlan] > >>And here we see why I'm such a fan of the term 'deferred expression' >>instead of 'anonymous function'. >> >>Python's lambda expressions *are* the former, but they are >>emphatically *not* the latter. > > Let me emphatically disagree. Your POV is entirely syntactical, which > IMO is a shallow perspective. Semantically, lambdas ARE anonymous > functions, and that's what counts. Interesting. Knowing this, I think I better understand your desire to get rid of lambda expressions for Py3K. > Since "deferred expression" is not defined in Python, you can't > reasonably argue about whether that's what lambdas are, but > intuitively for me the term refers to something more lightweight than > lambdas. As you say, it is a matter of looking at lambdas based on what the current syntax restricts them to (i.e. single expressions), rather than what the underlying machinery is capable of (i.e. full-fledged functions). > Now, whether the use cases for lambdas are better served by anonymous > functions or by something else that might be called deferred > expression, I don't know yet. Like you (judging by your stated goals for Py3K), I don't have any use cases for full anonymous functions - named functions serve that role quite happily for me. Where I find lambda expressions useful is the role that Python's current syntax restricts them too - functions which consist of a single (usually simple) expression. For those, pulling the expression out and naming it would just end up hiding the meaningful sections of code behind a few pieces of boilerplate > But as long as we are describing the > present state we should call a spade a spade, etc. I guess I take a syntactic view of the status quo, because, while lambdas may be implemented as anonymous functions, the current syntax doesn't let me *write* an arbitrary function as a lambda. Regardless, I believe the balance will eventually tip in some direction - either lambdas disappear entirely, become able support full anonymous functions, or else the idea of a 'deferred expression' becomes a defining characteristic, rather than a syntactic quirk. I figure it's all Py3K type stuff though, without any great urgency associated with it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
>>>lambda x,y: x+y*y >>>lambda x,y: y**2+x >>> are essentialy the same functions with different implementations [1]. >> Except that they are not. Think of __pow__, think of __add__ and __radd__. > You know the difference between the concept of a function and it's > infinitely many representations? That's why formal definitions exist. To clear up the archives, the problem is that Kay and Reinhold were talking about different things when they said "function". In arithmetic (and most sane extensions), those two lines are essentially the same function written different ways. In python those two lines represent two different functions, because x and y might not be (bound to) sane numbers. The variables could be bound to objects that redefine the addition, multiplication, and exponentiation operators. So y*y might not be the same as y**2, and x+y might not be the same as y+x. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
[Nick Coghlan] > And here we see why I'm such a fan of the term 'deferred expression' > instead of 'anonymous function'. > > Python's lambda expressions *are* the former, but they are > emphatically *not* the latter. Let me emphatically disagree. Your POV is entirely syntactical, which IMO is a shallow perspective. Semantically, lambdas ARE anonymous functions, and that's what counts. Since "deferred expression" is not defined in Python, you can't reasonably argue about whether that's what lambdas are, but intuitively for me the term refers to something more lightweight than lambdas. Now, whether the use cases for lambdas are better served by anonymous functions or by something else that might be called deferred expression, I don't know yet. But as long as we are describing the present state we should call a spade a spade, etc. (Alas, no time to follow the rest of this thread -- vacationing with little connectivity until EuroPython starts next week.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reinhold Birkenfeld wrote: > >>> >>>lambda x,y: x+y*y >>>lambda x,y: y**2+x >>> >>> are essentialy the same functions with different implementations [1]. >> >> >> Except that they are not. Think of __pow__, think of __add__ and __radd__. > > You know the difference between the concept of a function and it's > infinitely many representations? That's why formal definitions exist. I must say that I don't understand what you're after. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Donovan Baarda <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > Donovan Baarda <[EMAIL PROTECTED]> wrote: > > > >>Nick Coghlan wrote: > >> > >>>Donovan Baarda wrote: > [...] > >>But isn't a function just a deferred expression with a name :-) > > > > > > A function in Python is actually a deferred sequence of statements and > > expressions. An anonymous function in Python (a lambda) is a deferred > > expression. > > in the end though, a sequence of statements that completes with a > "return value" is, when treated as a black box, indistinguishable from > an expression. Originally I thought that this also had to be qualified > with "and has no side-effects", but I see now that is not the case. Lambdas/anonymous functions are generally used when they are simple and are either to be applied _now_, or passed as a callback to someone else (sometimes people use the x = lambda..., but that is laziness, def/return is clearer). Are either of the following two examples easy to read? rslt = (def (arg): #body that handles arg ... )(argument_passed_to_fcn) foo((def (arg): #body that handles arg ... ), foo_arg, ...) I personally think they are horrible. Both of the above would be easier to read as... def _throw_away(arg): #body that handles arg ... rslt = _throw_away(argument_passed_to_fcn) foo(_throw_away, ...) > [...] > >>Oh yeah Raymond: on the "def defines some variable name"... are you > >>joking? You forgot the smiley :-) > > > > > > 'def' happens to bind the name that follows the def to the function with > > the arguments and body following the name. > > Yeah, but we don't use "def" to bind arbitary variables, only > functions/procedures. So in python, they are intimately identified with > functions and procedures. Being that this entire thread is about functions, perhaps there was an implied "function" in there? Also, with the right decorator, it becomes an arbitrary assignment method in Python 2.4 ... >>> def assign(val): ... return lambda a:val ... >>> @assign(5) ... def foo(arg): pass ... >>> foo 5 >>> > >>If there really is a serious practical reason why they must be limited > >>to expressions, why not just raise an exception or something if the > >>"anonymous function" is too complicated... > > > > > > Define "too complicated"? > > I was thinking that this is up to the interpreter... depending on what > the practical limitations are that cause the limitation in the first > place. For example... if it can't be reduced to an "expression" through > simple transforms. Care to write the transformation library for all Python statements? Care to see that multi-line anonymous function I described above? I certainly hope not. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > Donovan Baarda wrote: > >>As I see it, a lambda is an anonymous function. An anonymous function is >>a function without a name. > > > And here we see why I'm such a fan of the term 'deferred expression' > instead of 'anonymous function'. > > Python's lambda expressions *are* the former, but they are > emphatically *not* the latter. Lambda's have inputs and outputs like a function, so they can be used in place of functions. A simple deferred expression wouldn't be the same thing since it would use local names directly, but not at the time the expression is created, and couldn't (easily) be used in place of a function call. addxy = defer x+y # do this later for x in range(10): for y in range(10): print addxy# prints sums of x,y This is basically a limited single expression macro. (Which I believe isn't wanted.) A better example might be as used in a dictionary in place of a case statement. ie.. case['add'] = defer x+y, etc... Regards, Ron (Reply to this in python-list if it would be better discussed there.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Skip Montanaro wrote: > >> As I see it, a lambda is an anonymous function. An anonymous function > >> is a function without a name. We already have a syntax for a > >> function... why not use it. ie: > >> > >> f = filter(def (a): return a > 1, [1,2,3]) > > Kay> You mix expressions with statements. > > You could remove the "return" and restrict the body of the def to an > expression: > > f = filter(def (a): a > 1, [1,2,3]) > > That looks almost exactly like a lambda, but uses "def" and parenthesizes > the argument list. It seems to me that would remind people "this is a > function". Yes, but skipping the name of a function ( anonymizing it ) is not a strong reason to disallow statements in the anonymus function body. The crucial issue is the notation of callable expressions that are not statements but can be defined inside of other expressions ( e.g. inside a filter() call as in the example ). That's why I prefer notations that emphasize the expression character. Using the arrow notation ( (args) -> expr ) would be fine for me but I would not deselect Python in favor for Java if ( expr from (args) ) is used instead. To me it's a "judean popular front" vs "popular front of judea" kind of thing. Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Reinhold Birkenfeld wrote: >> >>lambda x,y: x+y*y >>lambda x,y: y**2+x >> >> are essentialy the same functions with different implementations [1]. > > > Except that they are not. Think of __pow__, think of __add__ and __radd__. You know the difference between the concept of a function and it's infinitely many representations? That's why formal definitions exist. > > Reinhold > > Just for refresh: "Formally, a function f from a set X of input values to a set Y of possible output values (written as f : X -> Y) is a relation between X and Y which satisfies: 1. f is total, or entire: for all x in X, there exists a y in Y such that x f y (x is f-related to y), i.e. for each input value, there is at least one output value in Y. 2. f is many-to-one, or functional: if x f y and x f z, then y = z. i.e., many input values can be related to one output value, but one input value cannot be related to many output values. A more concise expression of the above definition is the following: a function from X to Y is a subset f of the cartesian product X × Y, such that for each x in X, there is a unique y in Y such that the ordered pair (x, y) is in f." http://en.wikipedia.org/wiki/Function_%28mathematics%29 Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
>> As I see it, a lambda is an anonymous function. An anonymous function >> is a function without a name. We already have a syntax for a >> function... why not use it. ie: >> >> f = filter(def (a): return a > 1, [1,2,3]) Kay> You mix expressions with statements. You could remove the "return" and restrict the body of the def to an expression: f = filter(def (a): a > 1, [1,2,3]) That looks almost exactly like a lambda, but uses "def" and parenthesizes the argument list. It seems to me that would remind people "this is a function". Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reduction provides often the advantage to make expressions/statements > scriptable what they are not in Python. Python is strong in scripting > classes/objects ( a big plus of the language ) but you can't simply use > the language to prove that > > lambda x,y: x+y*y > lambda x,y: y**2+x > > are essentialy the same functions with different implementations [1]. Except that they are not. Think of __pow__, think of __add__ and __radd__. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote:
> I don't get what the problem is with mixing statement and expression
> semantics... from a practial point of view, statements just offer a
> superset of expression functionality.
>
> If there really is a serious practical reason why they must be limited
> to expressions, why not just raise an exception or something if the
> "anonymous function" is too complicated...
>
> I did some fiddling and it seems lambda's can call methods and stuff
> that can have side effects, which kinda defeats what I thought was the
> point of "statements vs expressions"... I guess I just don't
> understand... maybe I'm just thick :-)
The whole point is that you are able to do all the basic control flow
operations like IF, FOR and WHILE using simple expressions ( like in
Pythons lambda ), the lambda statement itself and recursion. Therefore
lambda expressions constitute a Turing complete language and they also
do so in Python. Different to many FP languages lambda plays no central
role in Python because statements won't be reduced to lambda expressions
( or some kind of ). They are merely an add-on.
Reduction provides often the advantage to make expressions/statements
scriptable what they are not in Python. Python is strong in scripting
classes/objects ( a big plus of the language ) but you can't simply use
the language to prove that
lambda x,y: x+y*y
lambda x,y: y**2+x
are essentialy the same functions with different implementations [1]. I
think this is a severe lack of expressibility and has nothing to do with
the silly objection that one has to write one more line for a simple
callback - o.k. I admit that I'm lazy too ;)
Regards,
Kay
[1] Not without hacking the parse tree. Doing so one might finally end
up accessing the expression in a simple modifieable manner:
>>> (lambda x,y: x+y*y).expr
('+',(x,'*',(y,y)))
>>> (lambda x,y: y**2+x).expr
('+',(('**',(y,2)),x))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Josiah Carlson wrote: > Donovan Baarda <[EMAIL PROTECTED]> wrote: > >>Nick Coghlan wrote: >> >>>Donovan Baarda wrote: [...] >>But isn't a function just a deferred expression with a name :-) > > > A function in Python is actually a deferred sequence of statements and > expressions. An anonymous function in Python (a lambda) is a deferred > expression. in the end though, a sequence of statements that completes with a "return value" is, when treated as a black box, indistinguishable from an expression. Originally I thought that this also had to be qualified with "and has no side-effects", but I see now that is not the case. [...] >>Oh yeah Raymond: on the "def defines some variable name"... are you >>joking? You forgot the smiley :-) > > > 'def' happens to bind the name that follows the def to the function with > the arguments and body following the name. Yeah, but we don't use "def" to bind arbitary variables, only functions/procedures. So in python, they are intimately identified with functions and procedures. >>I don't get what the problem is with mixing statement and expression >>semantics... from a practial point of view, statements just offer a >>superset of expression functionality. > > > Statements don't have a return value. To be more precise, what is the > value of "for i in xrange(10): z.append(...)"? Examine the selection of > statements available to Python, and ask that question. The only one > that MAY have a return value, is 'return' itself, which really requires > an expression to the right (which passes the expression to the right to > the caller's frame). When you have statements that ultimately need a > 'return' for a return value; you may as well use a standard function > definition. Hmmm. For some reason I thought that these kind of things would have a return value of None, the same as a function without an explicit return. I see now that this is not true... >>If there really is a serious practical reason why they must be limited >>to expressions, why not just raise an exception or something if the >>"anonymous function" is too complicated... > > > Define "too complicated"? I was thinking that this is up to the interpreter... depending on what the practical limitations are that cause the limitation in the first place. For example... if it can't be reduced to an "expression" through simple transforms. But look... I've gone and created another monster thread on "alternatives to lambda"... I'm going to shut up now. -- Donovan Baarda ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Donovan Baarda <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > Donovan Baarda wrote: > > > >>As I see it, a lambda is an anonymous function. An anonymous function is > >>a function without a name. > > > > > > And here we see why I'm such a fan of the term 'deferred expression' > > instead of 'anonymous function'. > > But isn't a function just a deferred expression with a name :-) A function in Python is actually a deferred sequence of statements and expressions. An anonymous function in Python (a lambda) is a deferred expression. > > Python's lambda expressions *are* the former, but they are > > emphatically *not* the latter. > > Isn't that because lambda's have the limitation of not allowing > statements, only expressions? I know this limitation avoids side-effects > and has significance in some formal (functional?) languages... but is > that what Python is? In the Python I use, lambda's are always used where > you are too lazy to define a function to do it's job. I've generally seen people use lambdas for things that don't require names in the current context; i.e. callbacks with simple executions. > To me, anonymous procedures/functions would be a superset of "deferred > expressions", and if the one stone fits perfectly in the slingshot we > have and can kill multiple birds... why hunt for another stone? Are "deferred expressions" perhaps another way of spelling "function closure"? > Oh yeah Raymond: on the "def defines some variable name"... are you > joking? You forgot the smiley :-) 'def' happens to bind the name that follows the def to the function with the arguments and body following the name. > I don't get what the problem is with mixing statement and expression > semantics... from a practial point of view, statements just offer a > superset of expression functionality. Statements don't have a return value. To be more precise, what is the value of "for i in xrange(10): z.append(...)"? Examine the selection of statements available to Python, and ask that question. The only one that MAY have a return value, is 'return' itself, which really requires an expression to the right (which passes the expression to the right to the caller's frame). When you have statements that ultimately need a 'return' for a return value; you may as well use a standard function definition. > If there really is a serious practical reason why they must be limited > to expressions, why not just raise an exception or something if the > "anonymous function" is too complicated... Define "too complicated"? > I did some fiddling and it seems lambda's can call methods and stuff > that can have side effects, which kinda defeats what I thought was the > point of "statements vs expressions"... I guess I just don't > understand... maybe I'm just thick :-) There is nothing stopping anyone from modifying anything in a lambda... a = list(...) pop = lambda:a.pop() lcycle = lambda: a and a.append(a.pop(0)) rcycle = lambda: a and a.insert(0, a.pop()) popany = lambda: a and a.pop(random.randrange(len(a))) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote: > Nick Coghlan wrote: >> And here we see why I'm such a fan of the term 'deferred expression' >> instead of 'anonymous function'. > > But isn't a function just a deferred expression with a name :-) According to the specific meaning of 'expression' in the Python grammar? No. > Isn't that because lambda's have the limitation of not allowing > statements, only expressions? I know this limitation avoids side-effects > and has significance in some formal (functional?) languages... but is > that what Python is? Personally, I believe it has to do with two things, one practical and one more stylistic/philosophical. Firstly, Python uses significant whitespace between statements, and to delineate sections of compound statements. Within expressions however, whitespace is essentially insignificant (except where it affects the tokenisation). Trying to embed suites (where whitespace can be significant) inside expressions (where whitespace is generally insiginificant) tends to result in a horrible mess, or else some rather unPythonic concepts (e.g. using something other than indentation to demarcate the suite). Secondly, trying to cram too much functionality into a single line is a questionable activity. The 'deferred expression' approach taken with lambdas is a hint that if the thing you're trying to defer is more complex than a single expression, it may be worth giving it a proper name via 'def'. > In the Python I use, lambda's are always used where > you are too lazy to define a function to do it's job. In simple cases, naming the expression to be deferred results in it gaining a prominence it doesn't deserve, possibly obscuring the purpose of the main statement. In such cases, deferred expressions are a better solution - it's merely unfortunate that Python's current syntax for the practice anything to write home about. > To me, anonymous procedures/functions would be a superset of "deferred > expressions", and if the one stone fits perfectly in the slingshot we > have and can kill multiple birds... why hunt for another stone? Because there is already a solution for the large birds - *named* functions. Unfortunately, using a named function for a simple deferred expression is like using a catapult to kill a canary. > If there really is a serious practical reason why they must be limited > to expressions, why not just raise an exception or something if the > "anonymous function" is too complicated... You'd still need a definition of 'too complicated' - which we already have for deferred expressions. Specifically "unable to be expressed as a single Python expression". >> Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant >> entries under 'real closures'. > > Where is that wiki BTW? I remember looking at it ages ago but can't find > the link anymore. http://wiki.python.org/moin/AlternateLambdaSyntax Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > Donovan Baarda wrote: > >>As I see it, a lambda is an anonymous function. An anonymous function is >>a function without a name. > > > And here we see why I'm such a fan of the term 'deferred expression' > instead of 'anonymous function'. But isn't a function just a deferred expression with a name :-) As a person who started out writing assembler where every "function" I wrote was a macro that got expanded inline, the distiction is kinda blurry to me. > Python's lambda expressions *are* the former, but they are > emphatically *not* the latter. Isn't that because lambda's have the limitation of not allowing statements, only expressions? I know this limitation avoids side-effects and has significance in some formal (functional?) languages... but is that what Python is? In the Python I use, lambda's are always used where you are too lazy to define a function to do it's job. To me, anonymous procedures/functions would be a superset of "deferred expressions", and if the one stone fits perfectly in the slingshot we have and can kill multiple birds... why hunt for another stone? Oh yeah Raymond: on the "def defines some variable name"... are you joking? You forgot the smiley :-) I don't get what the problem is with mixing statement and expression semantics... from a practial point of view, statements just offer a superset of expression functionality. If there really is a serious practical reason why they must be limited to expressions, why not just raise an exception or something if the "anonymous function" is too complicated... I did some fiddling and it seems lambda's can call methods and stuff that can have side effects, which kinda defeats what I thought was the point of "statements vs expressions"... I guess I just don't understand... maybe I'm just thick :-) > Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant > entries under 'real closures'. Where is that wiki BTW? I remember looking at it ages ago but can't find the link anymore. -- Donovan Baarda ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote: > I must admit I ended up deleting most of the "alternative to lambda" > threads after they flooded my in box. So it is with some dread I post > this, contributing to it... I must admit you are right. And I will stop defending my proposal because it seems to create nothing more than pointless polemics. Suggesting elements of FP to python-dev may have the same chances to be accepted than raising a Buddha statue in a catholic church. > As I see it, a lambda is an anonymous function. An anonymous function is > a function without a name. We already have a syntax for a function... > why not use it. ie: > > f = filter(def (a): return a > 1, [1,2,3]) You mix expressions with statements. This is a no-go in Python. Permitting those constructs is a radical language change not just a simple syntax replacement. Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > Kay Schluehr <[EMAIL PROTECTED]> wrote: > >> The arrow is a straightforward punctuation for function definitions. > >> Reusing existing keywords for different semantics seems to me as a kind > >> of inbreeding. > > > > That's starting to look like the pseudocode from old algorithms > > textbooks, which is very similar to bad pseudocode from modern CS theory > > papers. Punctuation as a replacement for words does not always win > > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...) > > Writing functions as arrows is very convenient not only in CS but also > in mathematics. Looking like pseudo-code was not one of Guidos Python > regrets if I remember them correctly. Apparently you weren't reading what I typed. I don't find '->' notation for functions to be readable, either in code, papers, or otherwise. In fact, when I teach my CS courses, I use Python, and in the case where I need to describe mathematical functions, I use a standard mathematical notation for doing so: 'f(x) = ...'. > >> For pushing anymus functions forward I propose to enable explizit > >> partial evaluation as a programming technique: > > > > If I remember correctly, we've got rightcurry and leftcurry for that (or > > rightpartial and leftpartial, or something). > > > Currying usually does not perform a function evaluation in order to > create another more special function. Partial evaluation is a dynamic > programming and optimization technique. Psyco uses specialization and > caching implicitely. I propose to use it explicitely but in a more > restricted context. I never claimed that currying was partial function evaluation. In fact, if I remember correctly (I don't use curried functions), the particular currying that was implemented and shipped for Python 2.4 was a simple function that kept a list of args and kwargs that were already passed to the curried function. When it got enough arguments, it would go ahead and evaluate it. > > I'll assume that you don't actually want it to rewrite the source, or > > actually return the source representation of the anonymous function > > (those are almost non-starters). > > > > Computer algebra systems store expressions in internal tree form, > manipulate them efficiently and pretty-print them in textual or latex > output on demand. There would be much more involved than a tree to tree > translation starting with Pythons internal parse tree and an evaluator > dedicated to it. Right, and Python is not a CAS. You want a CAS? Use Mathematica, Maple, or some CAS addon to Python. Keeping the parse tree around when it is not needed is a waste. In the code that I write, that would be 100% of the time. > > As for all anonymous functions allowing partial evaluation via keywords: > > it would hide errors. Right now, if you forget an argument or add too > > many arguments, you get a TypeError. Your proposal would make > > forgetting an argument in certain ways return a partially evaluated > > function. > > > That's why I like to dump the function in a transparent mode. Personally > I could dispense a little security in favor for cheap metainformation. It's not about security, it's about practicality and backwards compatibility. Here is an example: >>> x = lambda a,b: a+b+1 >>> x(a=1) Traceback (most recent call last): File "", line 1, in ? TypeError: () takes exactly 2 non-keyword arguments (1 given) >>> According to you, that should instead produce... lambda b: 1+b+1 New and old users alike have gotten used to the fact that calling a function without complete arguments is an error. You are proposing to make calling a function with less than the required number of arguments not be an error. For the sake of sanity, I have to be -1000 on this. I'm also not aware of an automatic mechanism for code compilation (in Python) that both attaches the parse tree to the compiled function, or allows for the conversion of that parse tree back to a source form, or allows one to replace variable references with constants. If you would care to write the pieces necessary, I'm sure you will find a use for it. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote: > As I see it, a lambda is an anonymous function. An anonymous function is > a function without a name. And here we see why I'm such a fan of the term 'deferred expression' instead of 'anonymous function'. Python's lambda expressions *are* the former, but they are emphatically *not* the latter. Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant entries under 'real closures'. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Josiah Carlson wrote: > > > Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > > > >> Maybe anonymus function closures should be pushed forward right now > not only syntactically? Personally I could live with lambda or several > >> of the alternative syntaxes listed on the wiki page. I must admit I ended up deleting most of the "alternative to lambda" threads after they flooded my in box. So it is with some dread I post this, contributing to it... As I see it, a lambda is an anonymous function. An anonymous function is a function without a name. We already have a syntax for a function... why not use it. ie: f = filter(def (a): return a > 1, [1,2,3]) The implications of this are that both functions and procedures can be anonymous. This also implies that unlike lamba's, anonymous functions can have statements, not just expressions. You can even do compound stuff like; f = filter(def (a): b=a+1; return b>1, [1,2,3]) or if you want you can use indenting; f = filter(def (a): b=a+1 return b>1, [1,2,3]) It also means the following becomes valid syntax; f = def (a,b): return a>b I'm not sure if there are syntactic ambiguities to this. I'm not sure if the CS boffins are disturbed by "side effects" from statements. Perhaps both can be resolved by limiting annonymous functions to expressions. Or require use of brackets or ";" to resolve ambiguity. This must have been proposed already and shot down in flames... sorry for re-visiting old stuff and contributing noise. -- Donovan Baarda ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Josiah Carlson wrote: > Kay Schluehr <[EMAIL PROTECTED]> wrote: > > >> Maybe anonymus function closures should be pushed forward right now not only syntactically? Personally I could live with lambda or several >> of the alternative syntaxes listed on the wiki page. >> > > > > >> But asking for a favourite syntax I would skip the "def" keyword from your def-arrow syntax proposal and use: >> >>((a, b, c) -> f(a) + o(b) - o(c)) >> > > ... > > > >> The arrow is a straightforward punctuation for function definitions. Reusing existing keywords for different semantics seems to me as a kind of inbreeding. >> > > > That's starting to look like the pseudocode from old algorithms > textbooks, which is very similar to bad pseudocode from modern CS theory > papers. Punctuation as a replacement for words does not always win > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...) > > Writing functions as arrows is very convenient not only in CS but also in mathematics. Looking like pseudo-code was not one of Guidos Python regrets if I remember them correctly. > -1 on the syntax offering. > > > >> For pushing anymus functions forward I propose to enable explizit partial evaluation as a programming technique: >> > > > If I remember correctly, we've got rightcurry and leftcurry for that (or > rightpartial and leftpartial, or something). > > Currying usually does not perform a function evaluation in order to create another more special function. Partial evaluation is a dynamic programming and optimization technique. Psyco uses specialization and caching implicitely. I propose to use it explicitely but in a more restricted context. >> >>> ((x,y) -> (x+1)*y**2) >> ((x,y) -> (x+1)*y**2) >> >> >>> ((x,y) -> (x+1)*y**2)(x=5) >> ((y) -> 6*y**2) >> > > > I'll assume that you don't actually want it to rewrite the source, or > actually return the source representation of the anonymous function > (those are almost non-starters). > > Computer algebra systems store expressions in internal tree form, manipulate them efficiently and pretty-print them in textual or latex output on demand. There would be much more involved than a tree to tree translation starting with Pythons internal parse tree and an evaluator dedicated to it. > As for all anonymous functions allowing partial evaluation via keywords: > it would hide errors. Right now, if you forget an argument or add too > many arguments, you get a TypeError. Your proposal would make > forgetting an argument in certain ways return a partially evaluated > function. That's why I like to dump the function in a transparent mode. Personally I could dispense a little security in favor for cheap metainformation. Regards, Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr <[EMAIL PROTECTED]> wrote: > Maybe anonymus function closures should be pushed forward right now not > only syntactically? Personally I could live with lambda or several > of the alternative syntaxes listed on the wiki page. > But asking for a favourite syntax I would skip the "def" keyword from > your def-arrow syntax proposal and use: > > ((a, b, c) -> f(a) + o(b) - o(c)) ... > The arrow is a straightforward punctuation for function definitions. > Reusing existing keywords for different semantics seems to me as a kind > of inbreeding. That's starting to look like the pseudocode from old algorithms textbooks, which is very similar to bad pseudocode from modern CS theory papers. Punctuation as a replacement for words does not always win (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...) -1 on the syntax offering. > For pushing anymus functions forward I propose to enable explizit > partial evaluation as a programming technique: If I remember correctly, we've got rightcurry and leftcurry for that (or rightpartial and leftpartial, or something). > >>> ((x,y) -> (x+1)*y**2) > ((x,y) -> (x+1)*y**2) > > >>> ((x,y) -> (x+1)*y**2)(x=5) > ((y) -> 6*y**2) I'll assume that you don't actually want it to rewrite the source, or actually return the source representation of the anonymous function (those are almost non-starters). As for all anonymous functions allowing partial evaluation via keywords: it would hide errors. Right now, if you forget an argument or add too many arguments, you get a TypeError. Your proposal would make forgetting an argument in certain ways return a partially evaluated function. -1 on partial evaluation. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > Guido van Rossum wrote: > >>>Recommend accepting just the basic PEP which only targets simple, >>>obvious cases. The discussed extensions are unattractive and should be >>>skipped. >> >> >>-1. The "unary colon" looks unPythonic to me. >> > > > Step 1 would be to require parentheses around the whole thing (ala > generator expressions) to make it easier to see where the deferred > expression ends. > > But all my use cases that I can think off the top of my head involve > 'sorted', where it wouldn't help at all because of the need for an > argument. > > So I'd rather see a serious discussion regarding giving lambdas a more > Pythonic syntax in general, rather than one that only applied to the > 'no-argument' case [1] > > Cheers, > Nick. > > [1] http://wiki.python.org/moin/AlternateLambdaSyntax > The 'expression-before-args' version using just the 'from' keyword is > still my favourite. > Maybe anonymus function closures should be pushed forward right now not only syntactically? Personally I could live with lambda or several of the alternative syntaxes listed on the wiki page. But asking for a favourite syntax I would skip the "def" keyword from your def-arrow syntax proposal and use: ((a, b, c) -> f(a) + o(b) - o(c)) ((x) -> x * x) (() -> x) ((*a, **k) -> x.bar(*a, **k)) ( ((x=x, a=a, k=k) -> x(*a, **k)) for x, a, k in funcs_and_args_list) The arrow is a straightforward punctuation for function definitions. Reusing existing keywords for different semantics seems to me as a kind of inbreeding. For pushing anymus functions forward I propose to enable explizit partial evaluation as a programming technique: Example 1: >>> ((x,y) -> (x+1)*y**2) ((x,y) -> (x+1)*y**2) >>> ((x,y) -> (x+1)*y**2)(x=5) ((y) -> 6*y**2) Example 2: def f(x): return x**2 >>> ((x,y) -> f(x)+f(y))(x=2) ((y) -> 4 + f(y)) Example 3: >>> ((f,x,y) -> f(x)+f(y))(f=((x)-> x**2), y=3) ((x) -> ((x)-> x**2))(x)+9) The keyword style argument passing can be omitted in case of complete evaluation where pattern matching on the argument tuple is applied. Regards, Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Guido van Rossum wrote: >>Recommend accepting just the basic PEP which only targets simple, >>obvious cases. The discussed extensions are unattractive and should be >>skipped. > > > -1. The "unary colon" looks unPythonic to me. > Step 1 would be to require parentheses around the whole thing (ala generator expressions) to make it easier to see where the deferred expression ends. But all my use cases that I can think off the top of my head involve 'sorted', where it wouldn't help at all because of the need for an argument. So I'd rather see a serious discussion regarding giving lambdas a more Pythonic syntax in general, rather than one that only applied to the 'no-argument' case [1] Cheers, Nick. [1] http://wiki.python.org/moin/AlternateLambdaSyntax The 'expression-before-args' version using just the 'from' keyword is still my favourite. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
[Raymond Hettinger] > This PEP is an excellent example of improving readability and usability > by omitting a keyword and simplifying syntax. It neither provides nor > takes away functionality; instead, it is a bit of a beautification > effort. > > Essentially it creates a lighter-weight, more usable syntax for > specifying deferred function arguments. Like decorators, this helps out > programmers who understand and use this technique, and it is harmless > and invisible for the rest. It is especially handy in the absence of an > if-then-else expression. The PEP is backwards compatible. > > Recommend accepting just the basic PEP which only targets simple, > obvious cases. The discussed extensions are unattractive and should be > skipped. -1. The "unary colon" looks unPythonic to me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
This PEP is an excellent example of improving readability and usability by omitting a keyword and simplifying syntax. It neither provides nor takes away functionality; instead, it is a bit of a beautification effort. Essentially it creates a lighter-weight, more usable syntax for specifying deferred function arguments. Like decorators, this helps out programmers who understand and use this technique, and it is harmless and invisible for the rest. It is especially handy in the absence of an if-then-else expression. The PEP is backwards compatible. Recommend accepting just the basic PEP which only targets simple, obvious cases. The discussed extensions are unattractive and should be skipped. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
