Live data from Hacker News

Functional programming in Python

docs.python.org

11–20 of 64 posts

Re: Functional programming in Python

#11

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

How about [item] + [some, list]?

Re: Functional programming in Python

#12
post #11

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

How about [item] + [some, list]?

That works but it's kind of a pain that the natural pythonic syntax: ['a'].extend(some-list) doesn't return a list.

Re: Functional programming in Python

#13

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

Maybe there's no way in the standard library, and it may be a valid point that it should be there, but you could trivially define your own 'cons' function and write cons(item, someList)

Re: Functional programming in Python

#14

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

namedtuple is awesome, until you realise it works internally by using eval and generating the source code of a class.

Re: Functional programming in Python

#15

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

Python lists are array-backed, Lisp lists are singly-linked lists. Appending to the front of an array list is O(n)--you don't want to do it. Appending to the back is constant time, but is an in-place operation and doesn't return anything, which is less than ideal for FP purposes.

Re: Functional programming in Python

#16
post #11

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

How about [item] + [some, list]?

Hmm, I forgot that '+' was overloaded for lists in Python - nevermind that last statement, then.

The rest still holds, though - not all functions have a mutable and immutable counterpart (like sort) and map() returning lists makes them rather unwieldy. I think they fixed this in Python 3, though I'm not sure if it was backported to 2.7.

Re: Functional programming in Python

#17

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

namedtuple is awesome, until you realise it works internally by using eval and generating the source code of a class.

And Lisps work internally by generating lists and evaluating those, but you don't see me complaining about macros!

In all seriousness, though, if I really wanted a functional implementation, I wouldn't be using Python. It's more just nice to know that I can create an object that's immutable and which functions more or less like a CLOS object, so that I can think in that mindset instead. Also, I believe it doesn't come with all of the hidden functions that it would otherwise.

In the end, if I really cared, I'd actually write a wrapper around the type() function.

Re: Functional programming in Python

#18

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

namedtuple is awesome, until you realise it works internally by using eval and generating the source code of a class.

namedtuple is still awesome. The fact that it's eval'ing a string to initialize it doesn't make that any less the case.

However, I'll agree that it would be disingenuous to say it's not a little peculiar, and surprising to see the source for it :)

Re: Functional programming in Python

#19
post #15

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

Python lists are array-backed, Lisp lists are singly-linked lists. Appending to the front of an array list is O(n)--you don't want to do it. Appending to the back is constant time, but is an in-place operation and doesn't return anything, which is less than ideal for FP purposes.

That's the problem. I can fake a functional paradigm within Python in some settings, but it falls apart at the seams.

Re: Functional programming in Python

#20

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

if you want to append to fronts and backs of lists, you should use deque: http://docs.python.org/library/collections.html#collections....
Post reply on HN