Why do calculator manufactures like to reinvent the wheel?

[debrouxl]

To expand on what Tim wrote:
* the Nspire's Lua is Lua at its core, but TI had to come up with a platform-specific set of APIs for event-driven programming (I'm told it maps nicely onto some existing UI frameworks), and additionally, TI butchered the standard runtime in such a way that the "io" and "os" packages are missing - IOW, among other similar arbitrary limitations, the Nspire's Lua cannot read or write files...
The Nspire's Lua has significant two-way incompatibilities with Lua for other platforms.

* a standard Python interpreter + the core libraries are indeed much larger than a standard Lua interpreter + the core libraries. I don't have footprint figures for the former, but the latter is usually said to require ~100 KB, give or take a factor of two depending on the platform.
At ~80 KB, my forward-ported, optimized version of an old, partial port of Lua 5.0.x to TI-68k/AMS made by someone else, is in that ballpark. It's missing support for stdin/stdout/stderr (those were never implemented for AMS), time/clock/date, and locales (bad for footprint), but standard file streams and time/clock/date would be far from doubling the size. At least, it can read and write files, among other features available from io.* and os.*.

* there's python-on-a-chip (p14p), which aims at making slimmed-down, special-purpose, library-less interpreters for a subset of Python. The base interpreter is something like 35 KB for TI-68k/AMS, embedded into each program. There's support for interactive debugging through whatever can be used as a serial port, but even after adding a subset of the standard library and for feeding scripts to the interpreter, I think it would remain too narrow for calculator manufacturers to base something on.