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
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
[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
[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
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:
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
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
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
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
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
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
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
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
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 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 b1, [1,2,3]) or if you want you can use indenting; f = filter(def (a): b=a+1 return b1, [1,2,3]) It also means the following becomes valid syntax; f = def (a,b): return ab 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
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 [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 stdin, line 1, in ? TypeError: lambda() 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
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
