Quick update: this is already possible ```> tai...

# python

[Piotr Krzemiński]

Quick update: this is already possible

> tail -1 python/experiments/python.kt 
fun returnString() = "Hello from Kotlin!"
> tail -2 python/experiments/out_ir.py 
def returnString():
    return 'Hello from Kotlin!'
> cat python/experiments/consumer.py 
from out_ir import returnString

print(returnString())
> python3.8 python/experiments/consumer.py 
Hello from Kotlin!

but for dead-simple functions - treat is a tracer bullet. I'm still working on getting the standard library to work. For now I just made it interpret without Python returning syntax error 🙂 so that the generated module can be loaded by Python and this little simple function can be invoked.

More importantly, I got in touch with @Roman Artemev [JB] from Kotlin compiler's team who gave me directions where to go next, like creating black-box tests. Roman is super-helpful, a pleasure to learn about Kotlin internals from him. So called 'box tests' are a bunch of high-level tests, some of them platform-specific, and some of them platform-agnostic. Ultimately I'm aiming at making all platform-agnostic box tests pass, and short-term I'll use this test infra to test against some simpler cases. As soon as simple functions using Kotlin's stdlib work properly, it will be another nice milestone.

[CLOVIS]

Nice! It's really interesting to see progress on this

[martmists]

Out of curiosity, why was the choice made to compile to python code rather than the pyc representation?

[Piotr Krzemiński]

We now have a layer of abstraction over generating Python code - we first produce an AST. Not sure if switching to generating pyc files would just require changing AST -> Python step, or more

[SerVB]

Yep, from what I know, bytecode can be specific to even a PATCH Python version, so I guess it would be difficult to support all the reasonable versions. On the other hand, when we have a py file as an output, we can do anything to it: run as is, compile to pyc, or even use a preprocessor to make it 2.X compatible (lib3to6).

All these extra steps can be implemented to be performed by the Kotlin plugin, if there is such demand.

@martmists, actually, why do you think it's better to have pyc?

[martmists]

There's various optimizations you can make to the bytecode that aren't possible with the cpython compiler. It would also not be unrealistic to output to compiled since that's what the JVM backend does too, and there you can also specify the target bytecode version, so I wouldn't call it illogical.

[martmists]

If anyone's wondering about the pyc header format, it's <version_magic_number:short>\r\n<flags:int><timestamp:int><source_size:int> (native byte ordering) if I remember correctly. As for differences between bytecode versions along with a list of magic numbers: https://stackoverflow.com/a/7807661/6122145

[Piotr Krzemiński]

Given that it's mostly about the ability to generate more optimal code and not some hard functional requirements, I'd say it's easier for us to stay with generating Python source for now. Thanks to this we'll deliver something that works sooner. Switching to generating bytecode now would introduce some overhead and given our resources for this project, it would slow us down. Once we have some "V1" that works, we can always reconsider it. Thanks for proposing it!

[SerVB]

I've just added this proposal as a card: https://github.com/krzema12/kotlin-python/projects/1#card-65171773