I'm not a huge fan of this for two reasons:

1. This makes the code less pythonic by default.
2. This is not an issue that the library by default should have to handle.

Fixing the first one is relatively easy, only add builtins if a name in builtins is a field name, I'll give the second a go so this can also be version conditional in the future.

I've opened an issue on the bpo https://bugs.python.org/issue45946 about this.

1. Fixed - add builtins. prefix only when needed.
2. Why do you think the library should not handle such a case? In practice, the tool generates a broken code from a valid proto file. Specifically, in my use-case, I use a third-party proto definition that falls into this issue which means I can't use this tool without the fix (and I really like to use it :))

I'm saying in an ideal world this shouldn't be fixed by us but by cpython.

Can you also add a test for this?

Assuming tests pass this looks much better than the original solution to this. Thank you!