Revisiting the Use of Underscore Prefixes in Marimo.

[hongyi-zhao]

This is a cont'd topic of #2124 (comment).

While I understand the current design decision regarding the use of underscore prefixes to signify private variables within cells, I'd like to open a discussion about potentially reconsidering this approach. Here are some points for consideration:

1. Code Readability: The frequent use of underscore prefixes can make the code less readable, especially in notebooks with many cells. This might impact the overall user experience and code comprehension.

2. Export Aesthetics: When exporting a notebook to a script using marimo export script notebook.py > script.py, the underscore prefixes are retained. This can make the exported code look less elegant and potentially less pythonic.

3. Alternative Approaches: Could we explore other ways to manage cell-specific variables without relying on underscore prefixes? For example:

   • Using a cell-specific namespace or dictionary
   • Implementing a more robust scoping mechanism within the Marimo runtime
   • Providing configuration options for users to choose their preferred variable naming convention

4. Consistency with Python Conventions: While underscores are used in Python to indicate private variables, they're typically used sparingly. The current approach in Marimo might be seen as overusing this convention.

5. User Customization: Could we consider adding an option for users to disable or customize this feature based on their preferences or specific use cases?

I appreciate the thoughtful design decisions that have gone into Marimo, and I understand that this particular choice was made consciously. However, I believe that revisiting this aspect could potentially enhance the user experience and code clarity in Marimo notebooks.

I'm interested in hearing the community's thoughts on this matter and whether others have experienced similar concerns or have additional suggestions for addressing this design aspect.

Regards,
Zhao

[akshayka]

Thanks for the thoughtful discussion post. We've indeed put a lot of thought into this.

Our recommendation is to avoid using local (underscore-prefixed) variables as much as possible; they are a crutch to help you migrate Jupyter notebooks. Python does have natural scoping mechanisms — functions and classes. If you look at our example code, you should hopefully find that we use private variables very sparingly, and instead encapsulate logic in functions.

Indeed, our documentation discourages the use of local variables:

Variables prefixed with an underscore are local to a cell (.e.g., _x). You can use this in a pinch to fix multiple definition errors, but try instead to refactor your code.

Using functions has the bonus of making your code more readable, more modular, and more re-usable.

There was another proposal, in #1477, to make it possible to reuse variable names in multiple cells so long as multiply defined variables are always defined before they are read. While possible for us to implement, it's somewhat complex (both for the user to understand and for us to implement) so we haven't supported this yet.

[hongyi-zhao]

Using functions has the bonus of making your code more readable, more modular, and more re-usable.

The problem is, that not all situations are suitable for this solution, and even if we adopt this method, we might still need to define multiple functions at a fine-grained level. In such cases, the issues mentioned here may still arise within these different functions.

[akshayka]

The only solution that I see may work is #1477. Unfortunately I don't think customization will work because it will make notebooks less portable across users -- all users should use a shared syntax.

You can learn more about the original thought process here: https://github.com/marimo-team/meps/blob/main/mep-0002.md

[ggggggggg]

I like the idea of having a cell optionally export no variables, and also optionally be able to explicitly list variables for export. But it is much more complex than the current way, and it's not clear it is worth that much additional complexity.