Allow explicit cell export (dependency) using return

[twitwi]

Description

When writing code cells that will probably end up into a function, I'd like to keep as many things as local variables. It is also the case by default in a notebook.

I'd like to be able to have a plain cell but specify what variables it exports.

Suggested solution

I'd suggest the use of return, which would replace the default return that marimo generates.

a = 12
b = 42
c = a+b
return c    # or a tuple of variable names

Alternative

One can use local marimo variables, which is sometimes ok, but the code becomes more difficult to change and requires modification if we want to make a (clean) function as the _ is not recommended that case.

_a = 12
_b = 42
c = _a+_b

The other solution is to introduce a function directly but its is more difficult to iterate over, it is error prone when modifying, seems less natural to people that don't know why we would do that and seems to duplicate part of the work of marimo.

def _():
   a = 12
   b = 42
   c = a+b
   return c
c = _()



### Additional context

_No response_

[twitwi]

One could also consider

a = 12
b = 42
c = a+b
return dict(c=c)

Which is more explicit and allows expressions in the return (not just variable names)

a = 12
b = 42
return dict(c=a+b)

(while the return a+b would make no sense marimo-wise)

[akshayka]

Thanks for the feature suggestion.

If the code will likely end up in a function, why not just start with it in a function that has a sensible name (not _), or refactor it into a function when ready? At least that is my workflow, and I find it works well.

The return proposal is certainly interesting. It does however add another thing for marimo newcomers to learn (eg, if a notebook using it is shared with them). Given that marimo already has a learning curve, I hesitate to add new concepts. In this case I'm not convinced that the incremental value provided by introducing new semantics (top-level return and implicit locals) merits the additional complexity.

[ggggggggg]

I like the spirit of the idea, not quite sure if it's right. As for why not just start with a function? I like to work a line or two at a time progressively, inspecting variables as I go. So as I'm writing the cell I actually want all the variables exported, but then I want a clean way to turn it into a function. I wonder if a cell action that refactors it into a function would be useful? Then it doesn't have as much of a learning curve, if you don't know about it, it doesn't affect you. Plus it would help with the "oops I forgot that this one was a global variable and forgot to add it as a function argument" problem since it would know all the variables you were relying on.

[dmadisetti]

A proposal (#719) for solving this was just to write:

def my_function():
   """This is my function"""
   c = a + b
   return c

in notebook mode, which would then get written to the output file as:

@app.fn
def my_function():
   """This is my function"""
   c = a + b
   return c

With some indication in notebook mode (autonaming of the cell I think and maybe something else) that the cell is a "python function". There's a longer discord discussion about this, but if this solution fits your problem, then maybe we'll utilize this issue for discussion

---

edit: if it wasn't clear this mode only kicks in if no "global" references are utilized- solving your issue. You could be certain everything was scoped as long as the indicator showed it was going to save in this form

[twitwi]

Thanks for your discussions. I took some time to think about it and experiment with writing functions right away.
I could not get a good feel of this approach, it is really painful to access variables, decide what to make global etc.
I understand the possible problem with the learning curve, so I'd totally understand if this proposal is set aside.

• overall, my proposal could be summed up as "I don't like the _ prefix convention for local variables, and I'd prefer to use an explicit return (or anything else, like "export" if it seems better to have a different keyword)",
• my pain point is true even if the cell is not meant to become a function soon,
• my workflow seems aligned with @ggggggggg where I want to explore the variables, so introducing a function right away (beyond the boilerplate) is not convenient,
• my main goal at first, is to limit what is exported by a cell (not necessarily to ensure that it does access global variables),
• the refactor action seems a nice and very interesting suggestion, independently of my "issue", maybe we should open a different issue for it
• I feel that the "if a cell contains a function then it becomes executed automatically" is troubling (I often write a function in a cell and I would not expect it to be run)

Thanks for this project.

[twitwi]

PS: I'm on the discord so if the discussion is public and I can contribute meaningfully, let me know where it is.

[dmadisetti]

You might be interested in using the scratchpad functionality more (little notebook icon)

1. You can reuse variable names
2. The variables defined in scratch don't pollute the normal notebook memory
3. When you are ready to clean up your code, there's a convenient import cell button that will put it in the notebook

[twitwi]

Hi, sorry for the delay, I was not working on marimo for some time.
After some playing with the scratchpad, it is indeed for small explorations that lead to early consolidation.

I feel however that my use of marimo is as a gigantic scratchpad (I'm writing directly python modules if it goes beyond exploratory), and I'm relying on dependencies between cells in this giant scratchpad mode.
My use case is probably not the most typical one, maybe we can close the issue.