Re: [PATCH v4 11/14] qapi/introspect.py: add type hint annotations

[John Snow <jsnow@redhat.com>]

On 2/8/21 4:39 PM, John Snow wrote:
>>
>> I'm once again terminally confused about when to use _lower_case and
>> when to use CamelCase for such variables.
>>
> 
> That's my fault for not using them consistently.
> 
> Generally:
> 
> TitleCase: Classes, Real Type Names :tm:
> lowercase: instance names (and certain built-in types like str/bool/int)
> UPPERCASE: "Constants". This is an extremely loose idea in Python.
> 
> I use the "_" prefix for any of the above categories to indicate 
> something not intended to be used outside of the current scope. These 
> types won't be accessible outside the module by default.
> 
> TypeVars I use "T", "U", "V", etc unless I bind them to another type; 
> then I use e.g. NodeT instead.
> 
> When it comes to things like type aliases, I believe I instinctively 
> used lowercase because I am not creating a new Real Type and wanted some 
> visual distinction from a real class name. (aliases created in this way 
> cannot be used with isinstance and hold no significance to mypy.)
> 
> That's why I used _stub, _scalar, _nonscalar, and _value for those types 
> there. Then I disregarded my own convention and used TreeValue; perhaps 
> that ought to be tree_value for consistency as it's not a Real Type :tm:
> 
> ...but then we have the SchemaInfo type aliases, which I named using the 
> same type name as they use in QAPI to help paint the association (and 
> pick up 'git grep' searchers.)
> 
> Not fantastically consistent, sorry. Feel free to express a preference, 
> I clearly don't have a universally applied one.
> 
> (Current leaning: rename TreeValue to tree_value, but leave everything 
> else as it is.)

Addendum: pylint wants any non-underscored type alias to be treated like 
a class name, as CamelCase.

I guess it just exempts underscore prefixed things. So, it does have to 
stay "TreeValue".

--js