QOTW: "... and to my utter surprise it worked." - Andrew Nagel on
his move from wxPython to programming Tkinter in desperation
"Python has more web application frameworks than keywords." - Skip
Montanaro (but probably others going back years)
Frithiof Andreas Jensen writes frankly on use of SNMP and netconf: http://groups.google.com/group/comp....2032bf92670fd7
Perhaps your application needs something like "ping". Several
distinct ways to achieve that exist: http://groups.google.com/group/comp....60d60b5942f1f/
You're going to hear about reddit.com, and about how it's been
REimplemented in Python. Here's a fraction of the commentary: http://reddit.com/blog/2005/12/night...ng-python.html http://www.aaronsw.com/weblog/rewritingreddit
Long discussions about Python documentation lead to no conclusion
this commentator knows how to summarize: http://groups.google.com/group/comp....470cb3cbc24d5/ http://groups.google.com/group/comp....2e5244a90a274/
aum's pygene genetic-algorithm solver "includes full api
documentation, and an implementation of the travelling
salesman problem ...": http://groups.google.com/group/comp....1fe0f886893d6/
Jibes against the lambda-clingers lead eventually to serious
questions of style in regard to variable namespacing,
lifespan, cleanup, and so on: http://groups.google.com/group/comp....e15cb6b8f2c32/
To say anything useful about IDEs apart from that one needs to
try each on for personal fit seems *very* difficult: http://groups.google.com/group/comp....26b6e6617a591/
================================================== ======================
Everything Python-related you want is probably one or two clicks away in
these pages:
Python.org's Python Language Website is the traditional
center of Pythonia http://www.python.org
Notice especially the master FAQ http://www.python.org/doc/FAQ.html
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.
For far, FAR more Python reading than any one mind should
absorb, much of it quite interesting, several pages index
much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/P...grammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html
comp.lang.python.announce announces new Python software. Be
sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=d...ython.announce
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/
The Python Package Index catalogues packages. http://www.python.org/pypi/
The somewhat older Vaults of Parnassus ambitiously collects references
to all sorts of Python resources. http://www.vex.net/~x/parnassus/
Much of Python's real work takes place on Special-Interest Group
mailing lists http://www.python.org/sigs/
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
Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usub...python%20patch
Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html
Python FAQTS http://python.faqts.com/
The Cookbook is a collaborative effort to capture useful and
interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python
Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php
For more, see http://www.syndic8.com/feedlist.php?...ShowStatus=all
The old Python "To-Do List" now lives principally in a
SourceForge reincarnation. http://sourceforge.net/tracker/?atid...70&func=browse http://python.sourceforge.net/peps/pep-0042.html
The online Python Journal is posted at pythonjournal.cognizor.com. ed****@pythonjournal.com and ed****@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
*Py: the Journal of the Python Language* http://www.pyzine.com
Archive probing tricks of the trade: http://groups.google.com/groups?oi=d...python&num=100 http://groups.google.com/groups?meta....lang.python.*
Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topic/python/ (requires subscription) http://groups-beta.google.com/groups...t=0&scoring=d& http://purl.org/thecliff/python/url.html (dormant)
or
http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python
There is *not* an RSS for "Python-URL!"--at least not yet. Arguments
for and against are occasionally entertained.
Suggestions/corrections for next week's posting are always welcome.
E-mail to <Py********@phaseit.net> should get through.
To receive a new issue of this posting in e-mail each Monday morning
(approximately), ask <cl****@phaseit.net> to subscribe. Mention
"Python-URL!".
-- The Python-URL! Team--
Dr. Dobb's Journal ( http://www.ddj.com) is pleased to participate in and
sponsor the "Python-URL!" project. 22  1962 
"Cameron Laird" <py********@phaseit.net> wrote in message
news:dn**********@lairds.us... Jibes against the lambda-clingers lead eventually to serious
questions of style in regard to variable namespacing,
lifespan, cleanup, and so on: http://groups.google.com/group/comp....e15cb6b8f2c32/
#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
In article <JO6mf.116$sF2.31@trnddc02>,
David Isaac <ai*****@verizon.net> wrote:
"Cameron Laird" <py********@phaseit.net> wrote in message
news:dn**********@lairds.us... Jibes against the lambda-clingers lead eventually to serious
questions of style in regard to variable namespacing,
lifespan, cleanup, and so on:
http://groups.google.com/group/comp....e15cb6b8f2c32/
#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: http://groups.google.com/group/comp....e15cb6b8f2c32/
Alan Isaac <ai*****@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" <py********@phaseit.net> wrote in message
news:dn**********@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.
Cheers,
Alan Isaac
Alan aka David 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.
But is it correct?
a0, a1, a2 = 1, 2, 3
x = 2
a0 + x*(a1 + x*(a2))
17 def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs)
.... horner([a0, a1, a2], x)
11
Are we merely employing different conventions for the order of coefficients
or is that simple and expressive lambda/reduce stuff obscuring an error?
Peter
Peter Otten wrote: Alan aka David 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.
But is it correct?
a0, a1, a2 = 1, 2, 3
x = 2
a0 + x*(a1 + x*(a2)) 17 def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs) ... horner([a0, a1, a2], x)
11
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.
On 12/9/05, David Isaac <ai*****@verizon.net> wrote: Jibes against the lambda-clingers lead eventually to serious
questions of style in regard to variable namespacing,
lifespan, cleanup, and so on:
http://groups.google.com/group/comp....e15cb6b8f2c32/
Alan Isaac <ai*****@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" <py********@phaseit.net> wrote in message
news:dn**********@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.
Cheers,
Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list
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" <__*******@web.de> wrote in message
news:dn*************@news.t-online.com... But is it correct?
Yes.
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.
Cheers,
Alan Isaac
"Chris Mellon" <ar*****@gmail.com> wrote in message
news:ma***************************************@pyt hon.org... 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.
Obviously opinions differ. See the discussion at http://www.artima.com/forums/flat.js...=30&msRange=15
I find many of the pleas for lambda persuasive as well.
For the contribution of lambda to maintainability,
see e.g. Gary Robinson's comment at that link.
Alan Isaac
Chris Mellon <ar*****@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?
# generate calculator keypad buttons
Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1)
Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1)
Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1)
Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2)
Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2)
Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2)
....
Paul Rubin wrote: Chris Mellon <ar*****@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?
# generate calculator keypad buttons
Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1)
Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1)
Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1)
Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2)
Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2)
Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2)
...
While I don't spend much time on GUIs, code like that would scream
"refactor" to me, e.g. something like:
class UserPressedButton(Button):
def __init__(self, i):
def command():
return user_pressed(i)
Button.__init__(self, label=str(i), command=command)
Button(7).grid(column=1, row=1)
Button(8).grid(column=2, row=1)
Button(9).grid(column=3, row=1)
Button(4).grid(column=1, row=2)
Button(5).grid(column=2, row=2)
Button(6).grid(column=3, row=2)
STeVe
Steven Bethard wrote: I thought stuff like the following was idiomatic in GUI programming.
Do you really want separate names for all those callbacks?
# generate calculator keypad buttons
Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1)
Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1)
Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1)
Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2)
Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2)
Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2)
...
While I don't spend much time on GUIs, code like that would scream
"refactor" to me, e.g. something like:
class UserPressedButton(Button):
def __init__(self, i):
def command():
return user_pressed(i)
Button.__init__(self, label=str(i), command=command)
Button(7).grid(column=1, row=1)
Button(8).grid(column=2, row=1)
Button(9).grid(column=3, row=1)
Button(4).grid(column=1, row=2)
Button(5).grid(column=2, row=2)
Button(6).grid(column=3, row=2)
a temporary factory function should be sufficient:
def digit(label, x, y):
def callback():
# print "BUTTON PRESS", label # debug!
user_pressed(int(label))
Button(label=label, command=callback).grid(column=x, row=y)
# create numeric pad
digit("7", 1, 1); digit("8", 2, 1); digit("9", 3, 1)
digit("4", 1, 2); digit("5", 2, 2); digit("6", 3, 2)
digit("1", 1, 3); digit("2", 2, 3); digit("3", 3, 3)
are people still missing that local functions are inexpensive in Python ?
</F>
Steven Bethard wrote: Paul Rubin wrote: Chris Mellon <ar*****@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?
# generate calculator keypad buttons
Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1)
Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1)
Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1)
Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2)
Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2)
Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2)
...
While I don't spend much time on GUIs, code like that would scream
"refactor" to me, e.g. something like:
class UserPressedButton(Button):
def __init__(self, i):
def command():
return user_pressed(i)
Button.__init__(self, label=str(i), command=command)
Button(7).grid(column=1, row=1)
Button(8).grid(column=2, row=1)
Button(9).grid(column=3, row=1)
Button(4).grid(column=1, row=2)
Button(5).grid(column=2, row=2)
Button(6).grid(column=3, row=2)
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.
"Fredrik Lundh" <fr*****@pythonware.com> writes: a temporary factory function should be sufficient:
def digit(label, x, y):
def callback():
# print "BUTTON PRESS", label # debug!
user_pressed(int(label))
Button(label=label, command=callback).grid(column=x, row=y)
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):
unops = {'sqrt': math.sqrt,
'sin': math.sin,
'cos': math.cos,
'tan': math.tan,
'ln': math.log,
'log': lambda x: math.log(x)/math.log(10),
'clr x': lambda x: 0
}
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?
Paul Rubin <http://ph****@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.
Paul Rubin wrote: "Fredrik Lundh" <fr*****@pythonware.com> writes: a temporary factory function should be sufficient:
def digit(label, x, y):
def callback():
# print "BUTTON PRESS", label # debug!
user_pressed(int(label))
Button(label=label, command=callback).grid(column=x, row=y)
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):
unops = {'sqrt': math.sqrt,
'sin': math.sin,
'cos': math.cos,
'tan': math.tan,
'ln': math.log,
'log': lambda x: math.log(x)/math.log(10),
'clr x': lambda x: 0
}
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?
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. bo****@gmail.com writes: How would you refactor that, with no lambda?
Or, why would you want to refactor that ?
I like it the way it was written. I'm not the one saying lambda is bogus.
On Mon, 12 Dec 2005 09:15:38 +0100, "Fredrik Lundh" <fr*****@pythonware.com> wrote: Steven Bethard wrote:
> I thought stuff like the following was idiomatic in GUI programming.
> Do you really want separate names for all those callbacks?
>
> # generate calculator keypad buttons
> Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1)
> Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1)
> Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1)
>
> Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2)
> Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2)
> Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2)
> ...
While I don't spend much time on GUIs, code like that would scream
"refactor" to me, e.g. something like:
class UserPressedButton(Button):
def __init__(self, i):
def command():
return user_pressed(i)
Button.__init__(self, label=str(i), command=command)
Button(7).grid(column=1, row=1)
Button(8).grid(column=2, row=1)
Button(9).grid(column=3, row=1)
Button(4).grid(column=1, row=2)
Button(5).grid(column=2, row=2)
Button(6).grid(column=3, row=2)
a temporary factory function should be sufficient:
def digit(label, x, y):
def callback():
# print "BUTTON PRESS", label # debug!
user_pressed(int(label))
Button(label=label, command=callback).grid(column=x, row=y)
# create numeric pad
digit("7", 1, 1); digit("8", 2, 1); digit("9", 3, 1)
digit("4", 1, 2); digit("5", 2, 2); digit("6", 3, 2)
digit("1", 1, 3); digit("2", 2, 3); digit("3", 3, 3)
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)
tweak 'til correct ;-)
Regards,
Bengt Richter bo**@oz.net (Bengt Richter) writes:
for tup in ((str(d+1), d%3+1,3-d//3) for d in xrange(9)): digit(*tup)
tweak 'til correct ;-)
GMTA. See: http://www.nightsong.com/phr/python/calc.py
written a couple years ago. It uses:
for i in xrange(1,10):
add_button(5+2-(i-1)/3, (i-1)%3, str(i))
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 <dn**********@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))
Ciao,
Marc 'BlackJack' Rintsch
Marc 'BlackJack' Rintsch wrote: In <dn**********@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))
Though I find the lambda form easier for me to understand but
itemgetter should be the preferred way as it should have some
performance advantage and sort are those kind of functions that need
it, in general.
In article <ma***************************************@python. org>,
Fredrik Lundh <fr*****@pythonware.com> wrote:
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Maurice LING |
last post by:
This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?
maurice
|
by: frr |
last post by:
Hi,
After upgrading to 2.4 (from 2.3), I'm getting a weird syntax error:
>>> import themes
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "themes.py", line...
|
by: Ville Voipio |
last post by:
I would need to make some high-reliability software
running on Linux in an embedded system. Performance
(or lack of it) is not an issue, reliability is.
The piece of software is rather simple,...
|
by: Kamilche |
last post by:
I switched to Python a couple years ago, and haven't looked back. I've
used Python for many applications, including several commercial plugins
for Poser. I don't post on here much, because I don't...
|
by: Mark Tarver |
last post by:
How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?
Note I'm not a Python person and I have no axes to grind here. This is
just a question for...
|
by: Rafael Almeida |
last post by:
Hello,
I'm studying compilers now on my university and I can't quite
understand one thing about the python interpreter. Why is its input a
binary file (pyc)? The LOAD_CONST opcode is 100 (dec)...
|
by: rtk |
last post by:
I'm looking for information on building a tiny/small/minimalist/
vanilla python interpreter. One that implements the core language and
a few of the key modules but isn't tied to any specific...
|
by: ureuffyrtu955 |
last post by:
Python is a good programming language, but "Python" is not a good
name.
First, python also means snake, Monty Python. If we search "python" in
google, emule, many results are not programming...
|
by: MonkeeSage |
last post by:
A quick question about how python parses a file into compiled
bytecode. Does it parse the whole file into AST first and then compile
the AST, or does it build and compile the AST on the fly as it...
|
by: Jack |
last post by:
I understand that the standard Python distribution is considered
the C-Python. Howerver, the current C-Python is really a combination
of C and Python implementation. There are about 2000 Python...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
