Dr. Dobb's Python-URL! - weekly Python news and links (Dec 7)

[Cameron Laird]

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.lang.python/msg/662032bf92670fd7

Perhaps your application needs something like "ping". Several
distinct ways to achieve that exist:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/ced60d60b5942f1f/

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.lang.python/browse_thread/thread/767470cb3cbc24d5/

http://groups.google.com/group/comp.lang.python/browse_thread/thread/94e2e5244a90a274/

aum's pygene genetic-algorithm solver "includes full api
documentation, and an implementation of the travelling
salesman problem ...":

http://groups.google.com/group/comp.lang.python/browse_thread/thread/9901fe0f886893d6/

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.lang.python/browse_thread/thread/ad0e15cb6b8f2c32/

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.lang.python/browse_thread/thread/eca26b6e6617a591/

=============== =============== =============== =============== ============
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/PythonProgrammersWeblog

http://www.planetpython.org/

http://mechanicalcat.net/pyblagg.html

comp.lang.pytho n.announce announces new Python software. Be
sure to scan this newsgroup weekly.

http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.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_usubject=weekly%20python%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?ShowMatch=python&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.c ognizor.com.
editor@pythonjo urnal.com and editor@pythonjo urnal.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=djq&as_ugroup=comp.lang.python&num=100

http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.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.c om/groups?oi=djq&a s_q=+Python-URL!&as_ugroup= comp.lang.pytho n
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 <Python-URL@phaseit.net > should get through.

To receive a new issue of this posting in e-mail each Monday morning
(approximately) , ask <claird@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.

[David Isaac]

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 7)


"Cameron Laird" <python-url@phaseit.net > wrote in message
news:dn7ibf$id0 $1@lairds.us...[color=blue]
> Jibes against the lambda-clingers lead eventually to serious
> questions of style in regard to variable namespacing,
> lifespan, cleanup, and so on:
>[/color]

http://groups.google.com/group/comp.lang.python/browse_thread/thread/ad0e15cb6b8f2c32/

#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

[Cameron Laird]

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 7)

In article <JO6mf.116$sF2. 31@trnddc02>,
David Isaac <aisaac0@verizo n.net> wrote:[color=blue]
>
>"Cameron Laird" <python-url@phaseit.net > wrote in message
>news:dn7ibf$id 0$1@lairds.us.. .[color=green]
>> Jibes against the lambda-clingers lead eventually to serious
>> questions of style in regard to variable namespacing,
>> lifespan, cleanup, and so on:
>>[/color]
>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
>
>[/color]

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?

[David Isaac]

Re: lambda (and reduce) are valuable

>>> Jibes against the lambda-clingers lead eventually to serious[color=blue][color=green][color=darkred]
>>> questions of style in regard to variable namespacing,
>>> lifespan, cleanup, and so on:
>>>[/color][/color][/color]

http://groups.google.com/group/comp.lang.python/browse_thread/thread/ad0e15cb6b8f2c32/

Alan Isaac <aisaac0@verizo n.net> wrote:[color=blue][color=green]
>> #evaluate polynomial (coefs) at x using Horner's rule
>> def horner(coefs,x) : return reduce(lambda a1,a2: a1*x+a2,coefs)[/color][/color]

"Cameron Laird" <python-url@phaseit.net > wrote in message
news:dn7ibf$id0 $1@lairds.us...[color=blue]
> 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?[/color]

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

[Peter Otten]

Re: lambda (and reduce) are valuable

Alan aka David Isaac wrote:
[color=blue][color=green][color=darkred]
>>> #evaluate polynomial (coefs) at x using Horner's rule
>>> def horner(coefs,x) : return reduce(lambda a1,a2: a1*x+a2,coefs)[/color][/color][/color]
[color=blue]
> It just cannot get simpler or more expressive.[/color]

But is it correct?
[color=blue][color=green][color=darkred]
>>> a0, a1, a2 = 1, 2, 3
>>> x = 2
>>> a0 + x*(a1 + x*(a2))[/color][/color][/color]
17[color=blue][color=green][color=darkred]
>>> def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs)[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> horner([a0, a1, a2], x)[/color][/color][/color]
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

[bonono@gmail.com]

Re: lambda (and reduce) are valuable


Peter Otten wrote:[color=blue]
> Alan aka David Isaac wrote:
>[color=green][color=darkred]
> >>> #evaluate polynomial (coefs) at x using Horner's rule
> >>> def horner(coefs,x) : return reduce(lambda a1,a2: a1*x+a2,coefs)[/color][/color]
>[color=green]
> > It just cannot get simpler or more expressive.[/color]
>
> But is it correct?
>[color=green][color=darkred]
> >>> a0, a1, a2 = 1, 2, 3
> >>> x = 2
> >>> a0 + x*(a1 + x*(a2))[/color][/color]
> 17[color=green][color=darkred]
> >>> def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs)[/color][/color]
> ...[color=green][color=darkred]
> >>> horner([a0, a1, a2], x)[/color][/color]
> 11
>
> Are we merely employing different conventions for the order of coefficients
> or is that simple and expressive lambda/reduce stuff obscuring an error?
>[/color]
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.

[Chris Mellon]

Re: lambda (and reduce) are valuable

On 12/9/05, David Isaac <aisaac0@verizo n.net> wrote:[color=blue][color=green][color=darkred]
> >>> Jibes against the lambda-clingers lead eventually to serious
> >>> questions of style in regard to variable namespacing,
> >>> lifespan, cleanup, and so on:
> >>>[/color][/color]
> http://groups.google.com/group/comp....e15cb6b8f2c32/
>
> Alan Isaac <aisaac0@verizo n.net> wrote:[color=green][color=darkred]
> >> #evaluate polynomial (coefs) at x using Horner's rule
> >> def horner(coefs,x) : return reduce(lambda a1,a2: a1*x+a2,coefs)[/color][/color]
>
> "Cameron Laird" <python-url@phaseit.net > wrote in message
> news:dn7ibf$id0 $1@lairds.us...[color=green]
> > 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?[/color]
>
> 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.
>[/color]

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.
[color=blue]
> Cheers,
> Alan Isaac
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>[/color]

[David Isaac]

Re: lambda (and reduce) are valuable

[color=blue]
> Alan Isaac wrote:[color=green][color=darkred]
> >>> #evaluate polynomial (coefs) at x using Horner's rule
> >>> def horner(coefs,x) : return reduce(lambda a1,a2: a1*x+a2,coefs)[/color]
> > It just cannot get simpler or more expressive.[/color][/color]


"Peter Otten" <__peter__@web. de> wrote in message
news:dne702$j1q $02$1@news.t-online.com...[color=blue]
> But is it correct?[/color]

Yes.
[color=blue]
> Are we merely employing different conventions for the order of[/color]
coefficients[color=blue]
> or is that simple and expressive lambda/reduce stuff obscuring an error?[/color]

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

[David Isaac]

Re: lambda (and reduce) are valuable


"Chris Mellon" <arkanes@gmail. com> wrote in message
news:mailman.19 45.1134220003.1 8701.python-list@python.org ...
[color=blue]
> 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.[/color]

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

[Paul Rubin]

Re: lambda (and reduce) are valuable

Chris Mellon <arkanes@gmail. com> writes:[color=blue]
> 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.[/color]

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)
....

[Steven Bethard]

Re: lambda (and reduce) are valuable

Paul Rubin wrote:[color=blue]
> Chris Mellon <arkanes@gmail. com> writes:
>[color=green]
>>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.[/color]
>
>
> 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)
> ...[/color]

While I don't spend much time on GUIs, code like that would scream
"refactor" to me, e.g. something like:

class UserPressedButt on(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

[Fredrik Lundh]

Re: lambda (and reduce) are valuable

Steven Bethard wrote:
[color=blue][color=green]
> > 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)
> > ...[/color]
>
> While I don't spend much time on GUIs, code like that would scream
> "refactor" to me, e.g. something like:
>
> class UserPressedButt on(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)[/color]

a temporary factory function should be sufficient:

def digit(label, x, y):
def callback():
# print "BUTTON PRESS", label # debug!
user_pressed(in t(label))
Button(label=la bel, command=callbac k).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>

[bonono@gmail.com]

Re: lambda (and reduce) are valuable


Steven Bethard wrote:[color=blue]
> Paul Rubin wrote:[color=green]
> > Chris Mellon <arkanes@gmail. com> writes:
> >[color=darkred]
> >>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.[/color]
> >
> >
> > 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)
> > ...[/color]
>
> While I don't spend much time on GUIs, code like that would scream
> "refactor" to me, e.g. something like:
>
> class UserPressedButt on(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)
>[/color]
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 .

[Paul Rubin]

Re: lambda (and reduce) are valuable

"Fredrik Lundh" <fredrik@python ware.com> writes:[color=blue]
> a temporary factory function should be sufficient:
>
> def digit(label, x, y):
> def callback():
> # print "BUTTON PRESS", label # debug!
> user_pressed(in t(label))
> Button(label=la bel, command=callbac k).grid(column= x, row=y)[/color]

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]

Re: lambda (and reduce) are valuable

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:[color=blue]
> 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?[/color]

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.