Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Origins of Python's “Functional” Features (2009)

python-history.blogspot.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Origins of Python's “Functional” Features (2009)

#31

Post by talideon »

wheaties wrote: post #26

I never understood his desire to remove 'reduce' from Python. I would love to hear a cogent reason as to why we should have to write a for-loop for everything 'reduce' like. In other languages, 'reduce' (akin to 'fold' for non-Python people) is one of the things you reach for daily.

The main issue is syntactic: Python's syntax is such that reduce() isn't terribly useful. If Python had an equivalent of blocks in Ruby or at least the ability to write non-trivial lambdas, I can see reduce() being useful, but as things stand, it's just kind of useless.

Re: Origins of Python's “Functional” Features (2009)

#32

Post by pyre »

mangecoeur wrote: post #25

I have sometimes wondered why python used 'lambda' for anonymous functions rather than just... well literally anonymous function - normal function syntax without the name. Could have been something like `def (x,y): x+y` This makes it sound like that was just how it was implemented. Nothing fundamentally wrong with lambda i guess

It's because lambda technically isn't an anonymous function. It's more like an anonymous expression. It probably helps to avoid confusion for people trying to do things that can't be expressions in it. E.g.:

    def (x,y): x += y

Re: Origins of Python's “Functional” Features (2009)

#33

Post by nerdponx »

mangecoeur wrote: post #25

I have sometimes wondered why python used 'lambda' for anonymous functions rather than just... well literally anonymous function - normal function syntax without the name. Could have been something like `def (x,y): x+y` This makes it sound like that was just how it was implemented. Nothing fundamentally wrong with lambda i guess

I suspect this is because

    def f(x, y): x+y
is valid one-line syntax for a regular function definition (that in this case computes `x+y` and returns `None` becaus Python does not have implicit returns). Maybe the parser could distinguish between them by saying that "if the function definition is all on one line and the function is missing its name, it's a lambda":

    def f(x,y): return x+y
    g = def x,y: x+y
    assert f(3,4) == g(3,4)
    assert f != g

 That said I have no
Nothing gives me the willies in mathematical code like writing out Greek letters. I don't know why, it just does. The fact that the otherwise excellent Stan (https://mc-stan.org) only accepts ASCII variable names is depressing. I would love to be able to actually write `map(λ x: x+7, range(5))`. I think a big reason why people don't use `map`/`reduce`/etc. more is that writing anonymous functions is still verbose (`lambda` is just too long a word) and relatively hard to read compared to list comprehension. Better still a syntax like `x -> x+7` would be ideal, since I'm pretty sure `->` would be a unique syntax element.

Re: Origins of Python's “Functional” Features (2009)

#34

Post by jgroszko »

tommikaikkonen wrote: post #16

While it's far from a functional language, I find that it's possible to build functional style abstractions without too much headache. The iterator protocol is so well supported by the language and the standard libraries that using map, filter, itertools, generator expressions & comprehensions gets you a long way. You get the rest of the way by writing any specialized combinators you need and then imperative code to…

Are there any public code bases out there that use this? Would be cool to see what sort of pipelines like this people are building and how they get used.

Re: Origins of Python's “Functional” Features (2009)

#35

Post by [deleted] »

ebola1717 wrote: post #9
Alex3917 wrote: post #5

Earlier quoted context omitted.

The one line would be functional. Here is a good example: list(filter(lambda x : ('widgets' in x), mixed_widgets))[0]['widgets'] I almost always go for more lines of readable code rather than less lines of unreadable code. But in cases like this, you can either write that as one line of garbage unreadable code or six lines of garbage unreadable code. So I'd rather just leave the overall codebase more dense to make it…

arghhh that's mostly unreadable because it's out of order. in ruby it's perfectly readable: mixed_widgets.filter { |x| x.contains('widgets') }[0]['widgets']

[deleted]

Re: Origins of Python's “Functional” Features (2009)

#36

Post by marcosdumay »

maweki wrote: post #21
tommikaikkonen wrote: post #16

While it's far from a functional language, I find that it's possible to build functional style abstractions without too much headache. The iterator protocol is so well supported by the language and the standard libraries that using map, filter, itertools, generator expressions & comprehensions gets you a long way. You get the rest of the way by writing any specialized combinators you need and then imperative code to…

The state of a generator is always a problem that trips me up the most when I try to do FP-Python. In general a function shouldn't care whether the input was a list, set or generator. While iterating over it (or yielding from it), we always mutate some internal state of the iterator. One solution would be, I think, to always pass tee-d copies of iterators and never(!) any iterator like it is (because you don't know w…

Personally, I run by a rule that I must consume a generator on the same line it is created, otherwise I use something that isn't lazy.

If you get some huge collection to scan, or wants to sync your code by sharing an iterator internal state, you may want to break that rule. But they are just too troublesome for my taste.

Re: Origins of Python's “Functional” Features (2009)

#37

Post by xapata »

Tulip68 wrote: post #27
xapata wrote: post #24

Earlier quoted context omitted.

Make your functions consumers. Don't pass tee'd iterators in, but tee after receiving if necessary. I don't see how find_first would cause any more problems than filter or sum.

That is a very bad idea in general and will lead to enormous memory leaks when large tee'd iterators get out of sync with one another. See here: This itertool may require significant auxiliary storage (depending on how much temporary data needs to be stored). In general, if one iterator uses most or all of the data before another iterator starts, it is faster to use list() instead of tee(). https://docs.python.org/2/…

Eh? I discouraged tee'ing iterators, or at least I thought I did.
Post reply on HN