> positioning your project as an alternative implementation of something is a losing proposition > don’t go trying to create a subset of Python I agree - a pr

> positioning your project as an alternative implementation of something is a losing proposition > don’t go trying to create a subset of Python I agree - a project that's marketed as "Python but with more X" is always going to struggle to compete with the canonical implementation. (Especially if X is speed - ultimately, if you're using a dynamically-typed language you probably don't care about execution speed). However, alternative implementations are not always doomed to failure. MicroPython seems to be somewhat successful, despite supporting little more than Python 3.4 (10 years old). It's designed to run on microcontrollers so it's not competing with CPython - it's competing with other microcontroller programming environments. OTOH, I'm sure the MicroPython maintainers get a lot of feature requests for more recent Python features. I once considered building an alternative implementation of Python that's lightweight and focused on embedding in applications - again, it wouldn't be competing with CPython, but with Lua. The number one feature request seemed to be "will it support NumPy?"