5 ms·

The fact that he proposed removing map, reduce, filter, and lambda from Python 3. In the case of map and filter, is there any compelling reason to use either o

• smanek 17y ago
  Nope - just a style thing. You don't need lambdas either - named functions are just as powerful. But I often think 'functionally.' Since I have options, I'd rather go with a language that allows me to program how I think - instead of being forced to translate my thought into its semantics.
  • azanar 17y ago
    Nope - just a style thing. You don't need lambdas either - named functions are just as powerful. It depends on what you define as power, and how wide of a continuum you are willing to presume that it runs. Named functions add two levels of clutter. The first is to the actual code, because you have to add a name to something that never wanted one, and it has to be defined apart from where it is used. You could give it a fluff name, but that is worse than no name at all. The reader is left wondering what the function is for, which requires carrying unnecessary mental baggage. It would seem more powerful to me that you just define a function where it is used, and not worry about having to carry around that extra mental information for later on; the less state you need to keep the better. But I may only say that because I, like you, tend to think functionally. The second is to the namespace, because now there is a symbol in the environment that doesn't need to be there. It's not a huge deal, but it is just another bit of extraneous fluff. Anyway, not meaning to turn this into a language war. Just a couple of thoughts that popped into my head when I read your first paragraph.
    • ellyagg 17y ago
      I agree with this big time. I hate increasing the "vocabulary" of my program unnecessarily.
    • d0mine 17y ago
      The "correct" alternative to multiline lambda might be not a named function but an explicit code block: no clutter at the prize of vertical space. result = [] for item in iterable: # here goes multiline lambda as an explicit suite # that computes value result.append(value)
• maxtilford 17y ago
  Obviously, map and filter are better because ... ah, hmm, I don't know. I think it is a matter of language design. Higher order functions are not as prominent in Python as say, Haskell, where map & friends are generally preferred for composability. Lispers prefer map & friends just because list comprehensions add all that messy syntax. If I were a Python programmer, I would probably use list comprehensions, since they seem to be the preferred idiom.
• riobard 17y ago
  A single, non-nested list comprehension or generator exp is basically map(filter). You need nesting to get filter(map). e.g. map(expensive_call, filter(cond, seq)) equals [expensive_call(each) for each in seq if cond(each)] but filter(cond, map(expensive_call, seq)) equals [each for each in [expensive_call(x) for x in seq] if cond(each)] note because of "expensive_call", it's inefficient (and silly) to do [expensive_call(each) for each in seq if cond(expensive_call(each))] So map/filter combination gives more flexibility than list comprehension, and for functional-thinking minds, it's just so natural to think in abstract terms of passing functions around. List comprehension is pretty syntactical sugar to do similar things, but it forces you think about the "how to do" instead of "what to do". That said, it's not really "compelling" though -- there is no real "compelling" reason to switch from one Turing-complete language to another given that you can do the same thing eventually. But hey, it's the itches that drive us nuts, isn't it? :) Just my 2 cents
  • amix 17y ago
    Most times you are interested in doing the simple, e.g.: filtered = [x for x in seq if x>10] Python's list comprehension is much more readable than using map/filter/reduce - at least for Python programmers :) Anyhow, I really like Guido's decision on dropping these - it creates a cleaner language and forces people to think Pythonic when programming in Python.
    • riobard 17y ago
      > Python's list comprehension is much more readable than using map/filter/reduce - at least for Python programmers For simple cases, yes. But I wouldn't say [each for each in [expensive_call(x) for x in seq] if cond(each)] is more readable than filter(cond, map(expensive_call, seq)) at least for functional-thinking minds. The level of thinking in abstract is different here. Now the problem is, some people see Python as a very functional language (with first-class functions etc) and want to use it that way (like Lisp), but BDFL and some core Python devs believe it is better to keep it Pythonic, thus those functional people are kinda pissed off by this and switch away from Python. Personally I don't think it will make Python a lot cleaner to remove two auxiliary functions and force people to use list comprehension when it is completely trivial to add these missing pair back (two lines of code). (disclosure: I prefer FP, but I also think keeping things Pythonic is fine most of the time. It's just that in this case, I think map/filter is pretty "Pythonic" according to me. :)
• pwnstigator 17y ago
  I like lambda because it allows anonymous functions-- functions that can be defined on the fly (dynamically) and then thrown away. IMO, it's generally bad form for a program to be dynamically creating named functions, filling the namespace. Also, I like map and filter because they aren't just functions in the procedural sense but combinators: you can pass them around, using them as arguments and returning them. It's much harder to pass around a syntactic entity like a list comprehension (although I'm glad list comprehensions exist; as shorthand they are great in source code.) All this said, I haven't used Python in 3 years, in favor of purely functional languages such as Clojure and ML, so I might be way out of date.
  • megaman821 17y ago
    You bring up a good point about passing map and filter around. I hadn't really thought of that. I still prefer to user list comprehensions, and don't think it would be so bad to have map, filter, reduce live in the itertools module. This would stylistically match what is done with the comparison operator functions living in their own module, which you can import if you need to pass the functions around.
    • pwnstigator 17y ago
      List comprehensions are great, but they're sort of a DSL-- something the syntax recognizes as special and converts to something else. It's unusual that you can pass around higher-order syntactic elements, while every modern language worth its salt allows you to pass around functions. Common Lisp has something similar, called LOOP. Implemented as a macro, it's a within-Lisp DSL for expressing looping constructs, e.g. (loop for i from 1 to 10 sum i) => 55 (loop for c across "bar" collect c) => (#\b #\a #\r) It's controversial within the CL community, because the loop language looks much more like traditional languages than Lisp.
      • gruseom 17y ago
        Indeed, we figured out recently that it's basically embedded Algol 68... which seems superbly fitting somehow.
• algorias 17y ago
  map, filter and reduce were not removed from python3.x, however. They'll be there for the next decade at least.