←back to thread

A tail calling interpreter for Python (already landed in CPython)

(blog.reverberate.org)
122 points phsilva | 1 comments | 17 Feb 25 07:12 UTC | HN request time: 0.209s | source
Show context
thunkingdeep ◴[20 Feb 25 03:19 UTC] No.43110710[source]▶
This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
replies(4): >>43110815 #>>43110832 #>>43111490 #>>43112657 #
beagle3 ◴[20 Feb 25 05:38 UTC] No.43111490[source]▶
It is not an optimization ; it changes program semantics - converts programs that will run out of stack eventually regardless of the amount of available memory (and raise exceptions an the process, for example, which a program might rely on. Either way, semantics are changed)

It should only be called Tail Call Elimination.

replies(2): >>43111684 #>>43111776 #
dragonwriter ◴[20 Feb 25 06:36 UTC] No.43111776[source]▶
By that standard, any optimization that changes scaling in any dimension changes semantics, which, well, I’m not saying its wrong, but I would say it is exactly what people looking for optimization want.
replies(3): >>43111911 #>>43112365 #>>43119601 #
1. rat87 ◴[20 Feb 25 20:16 UTC] No.43119601[source]▶
The important thing is whether theres a garuntee of it happening in particular circumstance or not. Like with python referencing counting theoretically finalizers should be called after you lose all references to a file (assuming no cycles) but you cant rely on it.

Python dicts were in insert sort order for 3.6 but this only became a garuntee as opposed to an implementation choice that could be changed at anyvtime with python3.7