Notices

1. Tek' or 1=1; -- (tek@freeradical.zone)'s status on Tuesday, 22-Jun-2021 21:52:17 CEST Tek' or 1=1; --

   I absolutely love writing Python code, but some parts of the community drive me nuts.

   Q: Why can't Python recursion be faster?A: "Deep recursion is evil" - https://stackoverflow.com/questions/67988828/why-is-python-recursion-so-expensive-and-what-can-we-do-about-it

   WTF. Deep recursion is freaking awesome, except that Python sucks at it because it doesn't have TCO. I bet if it added TCO, the same people would be saying deep recursion is the best thing ever.

   • Tek' or 1=1; -- (tek@freeradical.zone)'s status on Tuesday, 22-Jun-2021 21:59:48 CEST Tek' or 1=1; --

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga I dig Guido, but I think he's wrong here. I'd hope he's rethought this since then:

     1st: I'd happy have a `@optimize_recursion` decorator that let *me* decide whether I wanted performance or debugability on a per-function basis.

     2nd: All implementations must be equally bad? ಠ_ಠ

     3rd: Recursion doesn't solve everything. Neither does FP or OOP, but Python supports those.

     4th: Sure, it'd be hard. But if someone wants to do it, yay!

   • Tek' or 1=1; -- (tek@freeradical.zone)'s status on Tuesday, 22-Jun-2021 22:07:42 CEST Tek' or 1=1; --

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga I think so too. I could see it being hard to use heuristics to decide which pattern to use, so let the programmer be explicit about it. I mean, today you can abuse `settrace` to do all sorts of weird and wonderful things to the call stack, and that's built in. Good tail call support couldn't possibly be potentially worse than that.