Origins of Python's “Functional” Features (2009)
python-history.blogspot.com
Origins of Python's “Functional” Features (2009)
1–10 of 37 posts
Re: Origins of Python's “Functional” Features (2009)
#2I love the functional aspects of Python. It's nice to break the monotony of loops every once and while.
Re: Origins of Python's “Functional” Features (2009)
#3I love the functional aspects of Python. It's nice to break the monotony of loops every once and while.
I dunno. I love the functional parts of Groovy. But with Python I generally only break out the functional stuff when it's a choice between one unreadable line of code with a comment or else six unreadable lines of code. (E.g. when parsing an API response with weird and arbitrary nesting.)
Re: Origins of Python's “Functional” Features (2009)
#4I love the functional aspects of Python. It's nice to break the monotony of loops every once and while.
I dunno. I love the functional parts of Groovy. But with Python I generally only break out the functional stuff when it's a choice between one unreadable line of code with a comment or else six unreadable lines of code. (E.g. when parsing an API response with weird and arbitrary nesting.)
Which is supposed to be functional in that example?
Re: Origins of Python's “Functional” Features (2009)
#5Earlier quoted context omitted.
I dunno. I love the functional parts of Groovy. But with Python I generally only break out the functional stuff when it's a choice between one unreadable line of code with a comment or else six unreadable lines of code. (E.g. when parsing an API response with weird and arbitrary nesting.)
Which is supposed to be functional in that example?
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 easier to understand the program flow, and then leave a comment explaining what that line is doing.
Re: Origins of Python's “Functional” Features (2009)
#6Earlier quoted context omitted.
Which is supposed to be functional in that example?
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…
[deleted]
Re: Origins of Python's “Functional” Features (2009)
#7Earlier quoted context omitted.
Which is supposed to be functional in that example?
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…
You could also use the list comprehension form of that:
[x for x in mixed_widgets if 'widgets' in x][0]['widgets']
Related: I wish the list type in Python included an analogue to dict's ".get(key, default)" operation.
Re: Origins of Python's “Functional” Features (2009)
#8Earlier 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…
You could also use the list comprehension form of that: [x for x in mixed_widgets if 'widgets' in x][0]['widgets'] More readable? I dunno. More "Pythonic"? Definitely. Related: I wish the list type in Python included an analogue to dict's ".get(key, default)" operation.
definitely more readable - it describes in basic english words what it's doing and it's basically the same as mathematical set notation. The main question to me is the performance implication though. Are generator expressions doing the iteration at C level like map and does that give performance parity then? What about branching - am I correctly assuming that filter is always faster than comprehensions or generator expressions with if-parts?
Re: Origins of Python's “Functional” Features (2009)
#9Earlier quoted context omitted.
Which is supposed to be functional in that example?
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']
Re: Origins of Python's “Functional” Features (2009)
#10Earlier 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…
You could also use the list comprehension form of that: [x for x in mixed_widgets if 'widgets' in x][0]['widgets'] More readable? I dunno. More "Pythonic"? Definitely. Related: I wish the list type in Python included an analogue to dict's ".get(key, default)" operation.
First, if your’re only interested in the first value, you should probably use a generator expression instead of a list comprehension, otherwise the loop will run for all mixed_widgets even though they won’t be used:
(x for x in mixed_widgets if 'widgets' in x)[0]['widgets']
next(x for x in mixed_widgets if 'widgets' in x)['widgets']
next(x['widgets'] for x in mixed_widgets if 'widgets' in x)