Double underscore breaks existing code in betterproto v2/master

[mikhainin]

Summary

Double underscore breaks existing code

Reproduction Steps

When we try compiling the following proto-file, the field field__json becomes field_json

syntax = "proto3";
package test;

message TestMessage {
  string field__json = 1;
}

@dataclass(eq=False, repr=False, config={"extra": "forbid"})
class TestMessage(betterproto.Message):
    field__json: str = betterproto.string_field(1)

 python -m grpc_tools.protoc --python_betterproto_opt=pydantic_dataclasses --python_betterproto_out=src -Isrc src/test.proto

Expected Results

If we build the same code with betterproto v1, or with the standard compiler (python -m grpc_tools.protoc --python_out=src --pyi_out=src src/test.proto) the field name will remain unchanged.

Not only does this break current code, but this will also impact how a dict/JSON is being generated based on the data class/structure.

I would imagine this behaviour as unwanted and if we want to sanitize filed name, I think it would be better to do in the original proto-file (e.g. using tools like buf).

Actual Results

above

System Information

protoc --version; python --version; poetry run pip show betterproto
libprotoc 27.3
zsh: command not found: python
Name: betterproto
Version: 2.0.0b7
Summary: A better Protobuf / gRPC generator & library
Home-page: https://github.com/danielgtaylor/python-betterproto
Author: Daniel G. Taylor
Author-email: [email protected]
License: MIT
Location: /Users/mikhailgalanin/Library/Caches/pypoetry/virtualenvs/betterproto-repro-O0YfRvug-py3.12/lib/python3.12/site-packages
Requires: grpclib, python-dateutil, typing-extensions
Required-by: betterproto-repro

Checklist

• I have searched the issues for duplicates.
• I have shown the entire traceback, if possible.
• I have verified this issue occurs on the latest prelease of betterproto which can be installed using pip install -U --pre betterproto, if possible.

[Gobot1234]

This is something that we do to make your code pythonic. You may be interested in #570

[mikhainin]

From what I understood, this happens in the snake_case() function. I could think of 2 ways how the experience can be improved:

1. we can introduce a plugin argument (i.e. use_strict_field_naming) to change the behaviour
2. we pass strict=False to the function when generating the field name
   patch-v1-define-snake-strictinness-via-cli-arg.patch
   patch-v2-use-non-strict-case-when-generate-field.patch