Be `allow_population_by_field_name` / `allow_population_by_field_name` value aware when suggesting field names
See original GitHub issueclass FooBase(BaseModel):
x: str
y: str = Schema(..., alias='special')
class Config:
alias_generator = str.upper
class SuperFoo(FooBase):
z: str
SuperFoo(X='field name is now upper case', special='Do not forget about alias in schema', Z='Zebra')
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:13 (10 by maintainers)
Top Results From Across the Web
Editing field names and descriptions - Amazon QuickSight
Change the names of fields in your dataset in Amazon QuickSight. ... You can change any field name and description from what is...
Read more >Guidelines for naming fields, controls, and objects
When you name a field, control, or object, it's a good idea to make sure the name doesn't duplicate the name of a...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
(Below, I’m going to refer to the
allow_population_by_alias
setting asallow_population_by_field_name
, the new name of the setting in v1.0, since it actually reflects the semantics and so is less confusing.)Here’s a proposal:
allow_population_by_field_name
isTrue
, always use the field names in the generated signatures (I can justify this choice if necessary, but won’t bother if we’re all on the same page)allow_population_by_field_name
isFalse
andalias_generator
is explicitly set, use the inferred field names (which will be aliases if specified in theField
; the same as it works now) in the generated signature, but also add a**kwargs
argument to the generated signature to prevent pycharm warnings due to the use of generated aliases if they can’t easily be inferred.**kwargs
argument should only be added ifallow_population_by_field_name
isFalse
! Otherwise, you should use the field names.It seems to me that this 1) shouldn’t be a great deal of work to implement, and 2) addresses most use cases very well (including both @skewty’s and my own)
@skewty if you take any issues with the above, could you describe the specific behavior you would like from the plugin? By that, I mean examples of:
I think that would make it easier to discuss concretely.
@dmontagu I would be okay with such a compromise and would welcome a release with that implemented 😃
PS: thank you all for all the time and energy that has been put into this plugin.