yeah, espesially as GvR's attitude so far seems to have been that functional programing is not in the style of python, and should be avoided. With the proposed removal of lambda and so on. Is this a change in policy? Will they make functional programing in Python reasonable? do we get tail call optimisations?
This comes up a lot. It doesn't help that some people often say with glee that Guido has said Python isn't a functional language. Like it's a big stick in the eye to every Lisper.
My own interpretation is that Guido has bristled at the suggestions by functional programming proponents that Python take on certain features simply because they are in other languages. These arguments are often presented with little justification involving real use cases. Similarly people will argue for features -- like truly private instance variables -- with the argument that this is required for Python to be a "real" object oriented language. The functional people at least have a pleasant academic air to their claims; the OO people often finish their argument with a "this is necessary for Python to be taken seriously in the enterprise."
But I digress... in reality, Python is a pretty decent functional programming language, with functional alternatives to many mutating operations (e.g., + instead of .extend(), sorted() instead of .sort()), closures, many immutable types, you can use tuple as the poor man's cons, and so forth.
If its any indication, the OO-flavored interface and adaptation proposals have lingered for years, in large part because Guido's resisted, or at least his apathy towards them. When generic functions were brought up as an alternative -- a much more functional approach to the same problems -- he warmed to it quickly.
Decorators are another case where a major functional feature has been adopted in Python, with pretty good uptake. It's not a pattern or syntax I see in other functional languages that much (at least I'm not aware of it), but it's still a strongly functional feature and is serving as the basis for many other functional constructs (including generic functions).
Some functional concepts are unlikely to get traction anytime soon, like tail call optimization. I would argue because tail call optimization is inaccessible to programmers who aren't steeped in recursive theory, and rather boring in its effect.
Lambda is syntactically -- not semantically -- awkward, but Python has true closures so the fundamental technique is still just as available. If you read Guido's explanation about why lambda isn't being improved, nor another function-expression syntax added, it's not that he thinks the idea of first class functions is wrong. First class functions are used all over the place in typical Python programs. It's just an issue of syntax.
The functional module itself is more about introducing functional language into Python, without rephrasing Python as a whole in those terms (hence partial is not added to builtins). Also it's just a place to put some functional patterns. Though there was discussion of renaming that module to just to functools, because the scope seemed a little funky -- there are functional constructs elsewhere in the standard library already (e.g., itertools), and some other routines seem related but not really "functional".
But I'm still curious: what other functional concepts aren't in Python that people think should be? Functional patterns that rely on removing ideas won't work -- like removing mutation -- but what is there that could be added to Python to make it more functional-friendly? I honestly can't think of a whole lot.
What I liked most about OCaml (and I think Haskell has it, too) is pattern matching. I don't think that it will ever make its way into python and I'm not sure if I liked it either.
But it's definately one of the cooler, functional language/syntax features out there.
Somehow it could be done, though.def insertElementIntoTree(tree, element): if element < tree.left: if (Pattern(tree) == Pattern(left=None) and element < tree.left: insertElementIntoTree(left) # ...
Anyway, it's kind of obscuring the code if Pattern would not become part of the standard library.
It is extremly easy to implement, by the way: http://home.in.tum.de/~bayerj/patternmatch.py
(not extremly well tested, just a scratch...)
Generic functions, or particularly RuleDispatch, accomplishes just this. Maybe like:@generic def insert_element(tree, el): raise NotImplementedError @insert_element.when('tree.left is None or el < tree.left') def insert_element_left(tree, el): insert_element(tree.left, el) ...
At least, I think that does what you want. I wouldn't bank on the performance of that algorithm ;) But the functionality is there, particular in RuleDispatch (which with arbitrary predicate dispatch is more general/powerful than what is being proposed for py3k). Well, I guess I'm not entirely clear on the intention f Pattern(left=None); I guess I'd express that as lambda tree: tree.left is None. I assume the distinction is primarily in a language like OCaml, where you can statically analyze aspects of patterns, which is not generally possible in Python.# Ian Bicking
Is the reason that you don't bank on the performance ;) that eval()-ing the condition in quotes would be a bottleneck?
It's not eval'd, it's compiled on import; it's just that doing that branching operation for every pass of a rather tight loop (in tree traversal) isn't an efficient way to do that operation.# Ian Bicking
www.katalog.wesnoth.pl holifld.info/katalog www.elate.pl/cat/ marek.holewinski.pl/katalog www.strony.pinia.pl www.dobredomy.pl/katalog/ www.artefakt.pl/katalog/ katalog.programisci.com.pl strony.shaco.pl katalog.twojapraca.info www.katalog.gigante.pl www.kat.plusk.info k1024.toreuse.pl b2b.wroclaw.pl/katalog/ news.stylokna.pl ale.biurka.pl k1024.telewizorek.pl stop.perfectfresh.com kat.gigahurt.pl www.strony.prbox.pl katalog.gcity.pl ups.markpol.biz www.coolmarket.net/katalog