[Feature request] Provide a optional pure-python mode like Cython does

[gabrieldemarmiesse]

Hi all, I speak as a library maintainer who likes this new language a lot!

I like the mentality of "Mojo meets developers where they are". And Python devs are making libraries and distributing them with Pypi. It would be awesome if Mojo could allow them to continue this workflow without another Pypi-like distribution or another codebase (maintaining two versions of the same library would be very sad!). Cython is very similar to mojo, has already been there and has a solution for this, the optional pure-python mode. You can see the doc here: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html

example:

Long story short, it would look like this:

# mojo syntax, supported if the user knows that he/she won't be using Python 
# to execute this file
struct MyPair:
    var first: Int
    var second: Int

    fn __init__(inout self, first: Int, second: Int):
        self.first = first
        self.second = second

    fn __lt__(self, rhs: MyPair) -> Bool:
        return self.first < rhs.first or
              (self.first == rhs.first and
               self.second < rhs.second)

# python mode, optional, strictly equivalent to the mojo code above, but can be executed too by the 
# python interpreter if needed. The Mojo compiler can use the directive to know that it can 
# read and execute the code even though it's a .py file
# ---------------------------------------


# compatible: mojo
from mojo_compatibility import struct, var, Int, inout, fn
from typing import Self

@struct
class MyPair:
    first: var[Int]
    second: var[Int]

    @fn
    def __init__(self: inout[Self], first: Int, second: Int):
        self.first = first
        self.second = second
    
    @fn
    def __lt__(self, rhs: MyPair) -> Bool:
        return self.first < rhs.first or
              (self.first == rhs.first and
               self.second < rhs.second)

Python users not working with mojo can still install this package if the package has the dependency mojo-compatibility (similary to cython being an importable module in pure python). Users can install it with pip install mojo-compatibility.

The Python compatiblity implementation

If one looks into the python definition of the mojo_compatibility module, they will see something very similar to cython:

# mojo_compatibility.py, will never be read by the Mojo compiler, but will be available in Pypi for python users.
from typing import Annotated

inout_annotation = object()
var_annotation = object()

def struct(my_class):
     return my_class  # we could override __setattr__ actually for better compatibility if we want.

def inout(x):
    return Annotated[x, inout_annotation]

def var(x):
    return Annotated[x, var_annotation]

Int = int
def fn(x):
    return x

That would allow mojo code to be easily distributed through Pypi and library maintainers to support both languages. Of course it would be a best-effort since not all the Mojo syntax can have a pure Python equivalent syntaxe.

Also note that this is purely optional and will likely be used by only a small portion of Mojo users, specifically the library maintainers.

Bonus

Cython has been handling this for quite a while, and they have a switch for this:

import cython

if cython.compiled:
    print("Yep, I'm compiled.")
else:
    print("Just a lowly interpreted script.")

If we could also have that in Mojo it would allow library maintainers to call libraries like numpy if executed with the python interpreter, and if executed with mojo, would be able to run the super fast mojo code directly (thus making numpy an optional dependency for example.

I really encourage people to take a look at Cython for the Python compatility, they do it very well :)

Conclusion

I believe this would jumpstart the distribution of mojo code since the infrastructure (pypi, wheels, pip, etc) is already there. Yes this optional syntax is combersome and not every feature of mojo can be supported through it, but library maintainers are usually advanced users who don't mind a few more lines here and there if it can help with maintainability and distribution.

[scrumtuous]

This seems like a smart and proven approach.

[ivellapillil]

While I can sympathize with the idea of compatibility with Python, we might have future Mojo constructs which will not be representable in Python at all. For example, if Mojo finds a way to have type annotations in lambda, it would be hard to do that in Python as AFAIK Python syntax does not allow it. Also it will add constraints to Mojo as in future the developers would expect that new syntax can be represented in Python compatibility mode also.

Another risk is that the Mojo codebase getting split into "clean" and "compatible " codebases...

Overall I am not so enthusiastic about this...