[Feature Request] Nudge new users away from calling dunder methods directly

[melodyogonna]

Review Mojo's priorities

• I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Is it possible for Mojo tooling like the LSP or compiler to nudge new users away from directly calling dunder methods by providing some diagnostic or warning?

What is your motivation for this change?

It's becoming obvious that new users without previous experience using Python do not understand how dunder methods work, nor how they fit into the language. It would be helpful if these new users were nudged into using dunder methods correctly.

Any other details?

You can check this video to see an example of what I'm talking about - https://youtu.be/mB_1SQlS_B0?si=KtpRjsYsJsxQfBpH&t=250

[soraros]

Ideas:

• De-emphasise them by sort them after ordinary methods in auto-completion.

  fn a()
  fn b()
  fn _a()
  fn __init__()

• Only show them in auto-completion if two leading underscores are present in the current "word buffer". Actually, we could apply the same rules to "private" methods (_*/__*).
  • _i shouldn't match __init__
  • init__ shouldn't match __init__
  • __ should match __init__

[nmsmith]

I would expect all accessible members of a struct to be displayed in auto-complete after you type the .. This allows you to browse the API of a type. Hiding some of the members would obscure the API.

But I agree that dunder methods should appear at the bottom of the auto-complete list.

The OP's issue—that learners are using dunder methods inappropriately—shouldn't be addressed by gimping auto-complete. 😢 It should be addressed by improving Mojo's educational materials!