How realistic is it in your eyes to create a "kotl...

# python

[Adolfo Ochagavía]

How realistic is it in your eyes to create a "kotlin multiplatform -> python" compiler that only supports a small subset of kotlin? I don't need IO, coroutines, threads, etc, and don't mind to abort compilation if those are present in the source code. For context, I have a parser written in kotlin multiplatform that I'd like to use from a Python project. I'm currently compiling to a shared library and loading it from Python, but I'd rather have pure Python code instead of relying on a platform-specific binary.

[Adolfo Ochagavía]

I'd hope that leaving out the more complex parts of kotlin would allow me to implement such a compiler with relative ease... But I don't know the kotlin compiler's internals, so I'm asking about it here to avoid embarking on an adventure that might be doomed from the start.

[Adolfo Ochagavía]

But maybe JS -> Python would be easier than dealing with kotlin at all

[Youssef Shoaib [MOD]]

See #C01EY9ZF9B5, where such a project has been attempted.
Btw, coroutines don't really need platform support. They're mostly implemented using a CPS transform, which is a fancy way of saying that suspend functions are turned into state machines and continuations are passed around, and all of that can be done in Kotlin's IR.

[Piotr Krzemiński]

hi, co-author of https://github.com/krzema12/kotlin-python here. If I were to pick up this project, I wouldn't continue it as a fork of the Kotlin compiler (as a separate backend), but as a processor that accepts either KLIB or LLVM IR. I think it's more realistic to have something working this way, but I don't have any estimates for you

[Piotr Krzemiński]

if we assume you know the input source code up front (your parser), you can easily start by covering the Kotlin features in the KLIB produced from your project

[Piotr Krzemiński]

Ah, the stdlib your project surely depends on in some way is somewhat a big chunk to be able to produce Python from

[Piotr Krzemiński]

see https://kotlinlang.slack.com/archives/C3SGXARS6/p1758353390565409

[Adolfo Ochagavía]

Thanks! I think I'll try compiling my parser to wasm first, since effort required here is so high

[Piotr Krzemiński]

So you have experience with using a Wasm binary from within Python?

[Adolfo Ochagavía]

I've worked with WebAssembly in the past and have been following it from a distance. Loading a wasm module in Python and calling its functions is almost as easy as importing a Python module (the wasmtime docs have a good example)

[Adolfo Ochagavía]

Wasm might just have reached enough maturity to be used as a replacement for native binaries, as long as a slight performance hit is acceptable. Ease of building/distributing the binaries is a great boon and you could even say it's more secure because the wasm module runs in a sandbox.

[Piotr Krzemiński]

looks very appealing! I wonder if it's possible to distribute a Wasm lib via pypi, and to make the consumer unaware that Wasm runs under the hood (=distribute with the runtime?)

[Adolfo Ochagavía]

That definitely sounds possible. My plan is to distribute a wheel that depends on wasmtime, which should get automatically installed by the user's package manager (this is the "right" approach, since you get a high-performance, mature runtime written in a native programming language and not in Python). Alternatively, you could develop a basic wasm runtime in pure python and ship its source code along with your project. Performance would then suffer a lot, since now you have one layer of interpretation for wasm and another one for Python, but that might be acceptable in some scenarios.