question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Be `allow_population_by_field_name` / `allow_population_by_field_name` value aware when suggesting field names

See original GitHub issue
class 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:open
  • Created 4 years ago
  • Reactions:1
  • Comments:13 (10 by maintainers)

github_iconTop GitHub Comments

2reactions
dmontagucommented, Oct 13, 2019

(Below, I’m going to refer to the allow_population_by_alias setting as allow_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:

  1. If allow_population_by_field_name is True, 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)
  2. If allow_population_by_field_name is False and alias_generator is explicitly set, use the inferred field names (which will be aliases if specified in the Field; 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.
    1. Note: the **kwargs argument should only be added if allow_population_by_field_name is False! 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:

  1. code that should raise warnings
  2. code that should not raise warnings
  3. how the configuration options you might have in mind would change the displayed warnings

I think that would make it easier to discuss concretely.

1reaction
skewtycommented, Oct 15, 2019

@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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found