| msg49386 - (view) |
Author: Collin Winter (collinwinter) *  |
Date: 2006-01-23 02:21 |
| This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. |
|
|
| msg49387 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2006-01-23 12:55 |
| Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. |
|
|
| msg49388 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2006-02-01 10:27 |
| Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. |
|
|
| msg49389 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2006-02-01 19:15 |
| Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. |
|
|
| msg49390 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2006-02-01 19:59 |
| Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. |
|
|
| msg49391 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2006-02-01 22:22 |
| Logged In: YES user_id=1344176 As stated in an earlier comment, I had already noticed the duplication and removed the relevant functions from my patch. The current member list is foldr, foldl, partial, flip, compose, id, scanl and scanr. All of these are implemented in C, removing the need for the special instructions outlined in the original message body. Is it necessary to go through the PEP process to see any of these members included in the module? |
|
|
| msg49392 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2006-02-01 23:09 |
| Logged In: YES user_id=80475 If you want to force this through over my objections, a PEP is a way to do it. Also, you can start a conversation on comp.lang.python, marshal support, and then take it to python-dev and ask for Guido to pronounce on it. However, do consider that there may be merit to my suggestion to first offer it as a third-party module. Then, if it is wildly successful, popular, and bug-free, there will be a better case for adding it to the standard library. At the very least, there should be an exercise to scan volumes of real-world code and find-out how often code would be improved by having these functional constructs. I think you will find that several of the functions are only of academic interest in a Python context. The existing language is already very accommodating. List comps and genexps reduce the need for functional constructs -- in particular, they allow arbitrary expressions and allow the programmer to avoid embedded lambdas and calls to the operator module. Also, do consider that these functions can be hard to use because it is difficult to remember the argument order, processing sequence, and handling of end-cases. That is why Guido and so many others hold reduce() in such low regard. Similar thoughts apply to foldr() and foldl(). I sense a desire to force this through because a) it can be done and b) these constructs have been successful in other languages. I do not sense a motivation based on user needs or the inability of the existing language to be able to solve certain classes of problems. To some degree, this programming style is at odds with the language and its goals for readability. A recurring design premise for Python is that is easier to remember how to compose or flip using pure Python than it is to learn and remember where to find a pre-made version in some module somewhere. These tools are so simple that it is hard to argue that they add any value at all. |
|
|
| msg49393 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2006-02-02 00:53 |
| Logged In: YES user_id=1344176 I'm not going to force it; somehow pissing off the python-dev crowd doesn't seem like the best route ;) This work is based more on scratching an itch of mine, a desire for more functional-style tools in Python. In any case, I've just released version 0.5 of just such a third-party module to PyPI (the name is "functional"). |
|
|
| msg49394 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2006-02-02 03:19 |
| Logged In: YES user_id=80475 Good luck with the module. Let us know how it fares in the real-world, whether it turns out to be indispensible or just a curiousity. |
|
|