On the goal of becoming an actual superset of Python and the default behavior of def()

[jordiae]

Hey, first of all thanks for working on Mojo, I have to say I'm definitely excited about this language!

One of the intended features of Mojo that makes it very attractive is the goal of becoming a superset of Python. But are we talking about actually being a superset in the strict sense? Asking this because some of the design choices don't seem to be compatible with Python, specifically the default behavior of def :

A def argument without a convention keyword (such as inout or owned) is passed by implicit copy into a mutable var with the same name as the argument. (This requires that the type have a __copyinit__ method.)

From https://docs.modular.com/mojo/programming-manual.html#comparing-def-and-fn-argument-passing

Isn't this incompatible with Python, in which arguments are typically passed by (mutable) reference?

[Mogball]

There is a nuance here. In Python, function arguments are technically passed by value. Python objects are reference counted pointers, and copying the pointer increments the reference count. The underlying data is accessed by reference still. You will notice this if you mutate an integer, floating point, or string value function argument in Python -- the effects are not visible to the caller. In Mojo, the PythonObject type is modelled precisely like this -- a pass by value object that can contain a reference counter pointer.

[jordiae]

Interesting! But in practice, doesn't this still mean that the following Python code:

def mutate_in_place(x):
    x.field += 1

is not going to be semantically equivalent if executed as Mojo code?

[Mogball]

It depends on the type of x. In Mojo, the type of x will be an object (when using untyped arguments in a def), which we have implemented as a reference-counted pointer, so Mojo will be able to support that kind of behaviour.

[jordiae]

Oh, understood. Many thanks for the clarification. Closing the discussion.