5 ms·

I agree completely. Other choice decisions include: "No tail-call-optimisation because I don't like recursion and I reckon the stack traces would probably be u

I agree completely. Other choice decisions include: "No tail-call-optimisation because I don't like recursion and I reckon the stack traces would probably be ugly" And "python doesn't need to be any faster" even though it should be possibly to do so without compromising development speed. If you want more functional style stuff in Python, check out Coconut: http://coconut-lang.org http://coconut-lang.org I think an ideal candidate would look like Coconut with its python X haskell feel. Maybe target LLVM for nice compile time checks and performance benefits.

naiveai 9y ago
People often attribute this to careful language design - and to be completely honest, I can't say anything about that since I'm just some kid, but I feel like that doesn't make the BDFL immune to criticism. TCO, for example, would change almost nothing that already exists in the language, and would make it faster in at least some cases. As evidenced by Coconut, and in fact the number of libraries that smack TCO onto Python, albeit in a very inelegant way. And sometimes it seems he intentionally cripples certain features so he can "prove" that certain ways of programming are bad. > filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, for example, x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension) (Quoted from https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196) If he had made lambdas even a little bit easier to write, then this criticism is completely blown out the window. I'm not saying that FP is the holy grail and all must bow down to the ivory tower. But it disturbs me that the BDFL seems to be waaayyyyyyy to cautious about adding useful features to the language because Python Is Not A Functional Language.

naiveai 9y ago

People often attribute this to careful language design - and to be completely honest, I can't say anything about that since I'm just some kid, but I feel like that doesn't make the BDFL immune to criticism. TCO, for example, would change almost nothing that already exists in the language, and would make it faster in at least some cases. As evidenced by Coconut, and in fact the number of libraries that smack TCO onto Python, albeit in a very inelegant way. And sometimes it seems he intentionally cripples certain features so he can "prove" that certain ways of programming are bad. > filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, for example, x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension) (Quoted from https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196) If he had made lambdas even a little bit easier to write, then this criticism is completely blown out the window. I'm not saying that FP is the holy grail and all must bow down to the ivory tower. But it disturbs me that the BDFL seems to be waaayyyyyyy to cautious about adding useful features to the language because Python Is Not A Functional Language.