WIwillghatch·Apr 15, 2020
As to `#lang python` interop with Racket, it's possible, but the farther a language's semantics and object model differ from Racket, the harder and less pleasant it is to build and use in practice.
In other words, you need converters between runtime values between Racket and Python when their semantics differ.
For example, Python strings are instances of Python's string class, with a bunch of methods, and you can mutate the string class at runtime.
They are very different from Racket's strings.
Then you have all the differences in core reduction semantics, how concurrency and parallelism is handled, etc, and there are a lot of differences to smooth over.
There is a project called PyonR (https://github.com/pedropramos/PyonR) that implements Python 2.7 as a Racket #lang, but it hasn't been developed for a while, and I'm not sure how interop
Read the rest
erable it actually is.
It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least.
The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code.
The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways.
While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc.
If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's.
Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!)
But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package.
It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.