======================================================================== Everything Python-related you want is probably one or two clicks away in these pages:
PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results.
Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/
Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success
The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html
The online Python Journal is posted at pythonjournal.cognizor.com. edi...@pythonjournal.com and edi...@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work.
del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python
======================================================================== Everything Python-related you want is probably one or two clicks away in these pages:
PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results.
Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/
Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success
The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html
The online Python Journal is posted at pythonjournal.cognizor.com. edi...@pythonjournal.com and edi...@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work.
del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python
>"Cameron Laird" <python-...@phaseit.net> wrote in message >news:dn7ibf$id0$1@lairds.us... >> Jibes against the lambda-clingers lead eventually to serious >> questions of style in regard to variable namespacing, >> lifespan, cleanup, and so on:
>#evaluate polynomial (coefs) at x using Horner's ruledef horner(coefs,x): >return reduce(lambda a1,a2: a1*x+a2,coefs)'Nuf said.Alan Isaac
No.
That is, this follow-up does *not* say enough for me to have confidence of its intent. Leaving aside such formalities as the relation between "Alan Isaac" and "David Isaac", I *think* you're supporting a claim about the value of lambda with a specific example. Do I have that right? Are you saying that your definition of horner() would suffer greatly without lambda?
>>> Jibes against the lambda-clingers lead eventually to serious >>> questions of style in regard to variable namespacing, >>> lifespan, cleanup, and so on:
Alan Isaac <aisa...@verizon.net> wrote: >> #evaluate polynomial (coefs) at x using Horner's rule >> def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) "Cameron Laird" <python-...@phaseit.net> wrote in message
> I *think* you're supporting a claim > about the value of lambda with a specific example. Do I have that > right? Are you saying that your definition of horner() would suffer > greatly without lambda?
It is a simple example of how lambda and reduce can be very expressive. Anyone who understands Horner's rule can see at a glance that this code implements it. Anyone who has bothered to learn what lambda and reduce do can see at a glance what the algorithm is.
It just cannot get simpler or more expressive.
Suffer greatly? Surely not. For "suffer greatly" you would probably need to turn to people who do a lot of event-driven GUI programming. But suffer, yes. Simplicity and expressiveness are valuable. That is the point.
>>> #evaluate polynomial (coefs) at x using Horner's rule >>> def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) > It just cannot get simpler or more expressive.
> Are we merely employing different conventions for the order of coefficients > or is that simple and expressive lambda/reduce stuff obscuring an error?
I think horner needs the coefs be "reversed", comparing with how we like to express polynomial in general, that is how I read those math formulas about horner anyway.
> >>> Jibes against the lambda-clingers lead eventually to serious > >>> questions of style in regard to variable namespacing, > >>> lifespan, cleanup, and so on:
> Alan Isaac <aisa...@verizon.net> wrote: > >> #evaluate polynomial (coefs) at x using Horner's rule > >> def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs)
> "Cameron Laird" <python-...@phaseit.net> wrote in message > news:dn7ibf$id0$1@lairds.us... > > I *think* you're supporting a claim > > about the value of lambda with a specific example. Do I have that > > right? Are you saying that your definition of horner() would suffer > > greatly without lambda?
> It is a simple example of how lambda and reduce can be very expressive. > Anyone who understands Horner's rule can see at a glance that this code > implements it. Anyone who has bothered to learn what lambda and reduce > do can see at a glance what the algorithm is.
> It just cannot get simpler or more expressive.
> Suffer greatly? Surely not. For "suffer greatly" you would probably need > to turn to people who do a lot of event-driven GUI programming. > But suffer, yes. Simplicity and expressiveness are valuable. > That is the point.
As someone who does a tremendous amount of event-driven GUI programming, I'd like to take a moment to speak out against people using us as a testament to the virtues of lamda. Event handlers are the most important part of event-driven code, and making them real functions with real names is crucial to maintainable code. The only reason to ever use a lamdba in Python is because you don't want to give a function a name, and that is just not a compelling use case for GUI events.
> Alan Isaac wrote: > >>> #evaluate polynomial (coefs) at x using Horner's rule > >>> def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) > > It just cannot get simpler or more expressive. "Peter Otten" <__pete...@web.de> wrote in message
> Are we merely employing different conventions for the order of coefficients > or is that simple and expressive lambda/reduce stuff obscuring an error?
It is too simple and expressive to obscure an error. ;-) This is particularly important since coefficient order is not standardized across uses.
> As someone who does a tremendous amount of event-driven GUI > programming, I'd like to take a moment to speak out against people > using us as a testament to the virtues of lamda. Event handlers are > the most important part of event-driven code, and making them real > functions with real names is crucial to maintainable code. The only > reason to ever use a lamdba in Python is because you don't want to > give a function a name, and that is just not a compelling use case for > GUI events.
Chris Mellon <arka...@gmail.com> writes: > As someone who does a tremendous amount of event-driven GUI > programming, I'd like to take a moment to speak out against people > using us as a testament to the virtues of lamda. Event handlers are > the most important part of event-driven code, and making them real > functions with real names is crucial to maintainable code. The only > reason to ever use a lamdba in Python is because you don't want to > give a function a name, and that is just not a compelling use case for > GUI events.
I thought stuff like the following was idiomatic in GUI programming. Do you really want separate names for all those callbacks?
Paul Rubin wrote: > Chris Mellon <arka...@gmail.com> writes:
>>As someone who does a tremendous amount of event-driven GUI >>programming, I'd like to take a moment to speak out against people >>using us as a testament to the virtues of lamda. Event handlers are >>the most important part of event-driven code, and making them real >>functions with real names is crucial to maintainable code. The only >>reason to ever use a lamdba in Python is because you don't want to >>give a function a name, and that is just not a compelling use case for >>GUI events.
> I thought stuff like the following was idiomatic in GUI programming. > Do you really want separate names for all those callbacks?
Steven Bethard wrote: > > I thought stuff like the following was idiomatic in GUI programming. > > Do you really want separate names for all those callbacks?
Steven Bethard wrote: > Paul Rubin wrote: > > Chris Mellon <arka...@gmail.com> writes:
> >>As someone who does a tremendous amount of event-driven GUI > >>programming, I'd like to take a moment to speak out against people > >>using us as a testament to the virtues of lamda. Event handlers are > >>the most important part of event-driven code, and making them real > >>functions with real names is crucial to maintainable code. The only > >>reason to ever use a lamdba in Python is because you don't want to > >>give a function a name, and that is just not a compelling use case for > >>GUI events.
> > I thought stuff like the following was idiomatic in GUI programming. > > Do you really want separate names for all those callbacks?
Well, that depends. This kind of coding many times are result of quick copy and paste. Whether it worths to abstract things out really depends on the life span. If it ends up never got touch again, the advntage of lambda is that I can just have it as is, it works, is clear to understand and everything is in place. I thought that is one of the advantage of python or quick prototyping.
This also is not a very good example as it shows some form of repetitiveness that is "screaming for refactoring". Many times, these fields are similar but have no common functionalities.
Looking at the calculator program I wrote a while back (one of my first Python programs, written just to play with tkinter), I see that I actually did something like that for the buttons. However, it also contained (in the other order):
Paul Rubin <http://phr...@NOSPAM.invalid> writes: > binops = {'+': (lambda x,y: x+y), > '-': (lambda x,y: x-y), > '*': (lambda x,y: x*y), > '/': (lambda x,y: x/y), > '**': (lambda x,y: x**y) > } > How would you refactor that, with no lambda?
Ok, with operator.add and so forth. I don't remember if I knew about those at the time. You can easily see though, how additional such simple functions might be wanted, that aren't in the operator module.
> Looking at the calculator program I wrote a while back (one of my > first Python programs, written just to play with tkinter), I see that > I actually did something like that for the buttons. However, it also > contained (in the other order):
Or, why would you want to refactor that ? The lambdas were used as the quickest and the most straight forward way to have the solution back then I believe. Refactoring is an aftermath(performance, frequent change to the same module for feature changes etc.). Without lambda, even the first version would force the programmer to think more about how to factor it and it seems in this case, not necessary and waste of precious programmer time.
>are people still missing that local functions are inexpensive in Python ?
OTOH, (untested)
for label, x, y in ((str(d+1), d%3+1, 3-d//3) for d in xrange(9)): Button(label=label, command=lambda d=int(label):user_pressed(d)).grid(column=x, row=y)
or
for tup in ((str(d+1), d%3+1,3-d//3) for d in xrange(9)): digit(*tup)
Chris Mellon wrote: > functions with real names is crucial to maintainable code. The only > reason to ever use a lamdba in Python is because you don't want to > give a function a name, and that is just not a compelling use case for > GUI events.
Ah, but that neglects the sheer utility of delayed-evaluation expressions. Consider the key= parameter to list.sort, et. al:
complicated_list.sort(key=lambda x: x[3])
Decorate-sort-undecorate is another way of doing this, but it's also boilerplate, involves list copies that have nothing to do with the flow of the program itself, and can possibly error (if done naively: key is comparable, but complex_list[i][0] isn't comparable, such as sorting a list of complex numbers by the real part, if two or more items have the same real).
The key= parameter was implemented just to make this sort of thing clearer and easier (and, in an odd way, actually more semantically explicit). The utility of a full function for the key= is nice and necessary, but simultaneously a lot of the uses are going to be for one-off expressions (like item[3]). There, the idea of a named function seems conceptual overkill.
The most significant problem with Python's lambda is that it's billed as an anonymous function, when it's really an encapsulated expression. My preferred solution is to replace lambda with something along the lines of an 'expression comprehension,' with similar syntax to list and generator comprehensions as-is:
lambda param1, param2: stuff_with(param2,param1) would become
<(param1, param2): stuff_with(param2, param1)> or, to become even more similar to comprehension syntax: <stuff_with(param2, param1) with (param1, param2)>
The only real problem, parsing-wise, with this syntax is that it can sometimes conflict with the << or >> operators if used without whitespace near comparisons.
The scope of what can be contained in the expression comprehension (lambda currently) is exactly the same as what can be contained in a list/generator comprehension, so why not capitalize on the parallelism?
In <dnmobd$5a...@rumours.uwaterloo.ca>, Christopher Subich wrote:
> Chris Mellon wrote: >> functions with real names is crucial to maintainable code. The only >> reason to ever use a lamdba in Python is because you don't want to >> give a function a name, and that is just not a compelling use case for >> GUI events.
> Ah, but that neglects the sheer utility of delayed-evaluation > expressions. Consider the key= parameter to list.sort, et. al:
> complicated_list.sort(key=lambda x: x[3])
This can be written as::
from operator import itemgetter complicated_list.sort(key=itemgetter(3))
