flatbuffers icon indicating copy to clipboard operation
flatbuffers copied to clipboard

Why don't you use PEP-8 compliant snake_case in Python implementation?

Open hubertpnj opened this issue 3 years ago • 9 comments

?

hubertpnj avatar Oct 15 '21 18:10 hubertpnj

Exactly

kebabdubaj avatar Oct 27 '21 16:10 kebabdubaj

Not sure... if that's the standard, we probably should.

aardappel avatar Oct 28 '21 20:10 aardappel

Sounds like a perfect case for a PR.

dbaileychess avatar Nov 09 '21 23:11 dbaileychess

I'm definitely interested in this, or more specifically flatc not mangling the names I use in my schema. Forcing everything to CamelCase makes the generated code harder to use because you cannot use the schema for documentation, and generated code usage diverges unnecessarily between languages.

I'd also be interested in seeing "proper" enums in generated code, at least optionally. This looks like a pretty simple change to flatc, but not-camel-casing things is a pretty huge one and I'm not sure what it might break.

Bklyn avatar Feb 15 '22 17:02 Bklyn

@rw

aardappel avatar Feb 15 '22 19:02 aardappel

I'm definitely interested in this, or more specifically flatc not mangling the names I use in my schema.

I may have taken this in a different direction than @hubertpnj 's original intent, which could be construed as being about the flatbuffers.py implementation details, not the generated code. I'm happy to split out my request to a separate issue if this is the case. I don't mean to muddy the waters here.

Bklyn avatar Feb 15 '22 23:02 Bklyn

@Bklyn please open a new issue with having the generated code be snake_case.

Do note, I am going to encourage that the schema naming follows our style guide.

dbaileychess avatar Feb 23 '22 01:02 dbaileychess

I'll made #7128 for this. I simply want names in the generated code to be left alone, at least optionally, in Python as they are in C++. We are using UpperCamelCase for type names and snake_case names for members of structs/tables, but the re-casing of everything, unconditionally, seems unnecessary. It is also not consistent across all languages. This inconsistency makes writing applications that use the generated code more difficult, since one cannot refer directly to the schema or examples in other languages as a guide for what names to use.

Bklyn avatar Feb 23 '22 18:02 Bklyn

I would request to reopen this ticket again, since #7128 has been closed in favor for #7111. But there has been no progress regarding #7111 it seems. PEP 8 is recommending to use lower_snake_case for functions and variable names. Would be happy to make a PR for fixing this in Python code generator at least.

t0hai avatar Sep 11 '23 12:09 t0hai

This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

github-actions[bot] avatar Mar 11 '24 20:03 github-actions[bot]

This issue was automatically closed due to no activity for 6 months plus the 14 day notice period.

github-actions[bot] avatar Mar 25 '24 20:03 github-actions[bot]