> ... for example, you don't have to def a print function for
> ftplib.retrlines() callback since you can now use 'lambda s : print
> str' to turn the statement print into a print function.
That won't actually work, because Python draws a sharp distinction
between what most languages call "expressions" and "statements", and
won't accept one where the other is expected. "lambda str : print str"
yields a syntax error in Python, because "print" is a statement and
lambda wants an expression (a "condition", as it's named in the formal
The current lambda syntax fits nicely in Python's view of the world (it's
an expression that can be used as a building block in larger
expressions), but a lambda containing (one or more) *statement*s doesn't.
Not to say that Guido couldn't turn the language inside out to make it
work, though ...
> But in some kinds of programming, which are just filthy with callbacks,
> it reads better to ``pretend'' that the function that takes the
> callbacks is a new flow-of-control construct. This is where TCL
> currently stands alone. It's not yet clear to me that Python can't
> outdo all the other modern scripting languages in their own strengths,
> but I don't yet see a way to create a python module that is as clear
> and beautiful as Don Libes' expect(1).
Trust me on this <wink>: Python can't beat other modern scripting
languages at their particular strengths. E.g., if you're on a UNIX(tm)
system, and don't use Perl for most straigtforward text-crunching
scripts, you're plain nuts. And I say this as a bona fide Python fanatic
who writes Perl scripts with the shuddery fascination usually reserved for
viewing train wrecks <0.9 grin>.
Code filthy with callbacks is prettier in TCL, and code filthy with
regexps is prettier in Perl, and code filthy with backtracking searches
is prettier in Icon, ... take your pick. Python shines at doing at least
"OK" at everything, despite that (more likely _because_) it doesn't aim
at making any particular application areas amazingly pleasant to tackle:
almost everything is done in the same syntactically simple way, by
invoking functions and classes imported from modules. The other
languages make some application areas amazingly _un_pleasant to tackle;
Python's extremely broad applicability is one of its unique strengths.
That's not to say ACLs aren't a good idea; it is to say that "this
_particular_ application is prettier in language X" is an argument that
can be made an unbounded number of times. Each time it's accepted, it
stands a good chance of harming a language overall (by introducing fresh
complexities that may or may not turn out to be cancerous -- e.g., Guido
put in a simple lambda, and now Steve & I are threatening him with
grievous bodily harm if he doesn't also fiddle Python's namespace model
to make the simple lambda more usable). Will ACLs make Python better
overall? I like them in the abstract, but I'm not sure they're a good
idea for _Python_.
y'rs - tim
Tim Peters firstname.lastname@example.org
not speaking for Kendall Square Research Corp