Argument name should be lowercase

[Thomas Passin]

This is a matter of convention.  Historically, many language 
practitioners got used to using all-caps for key constants.  This makes 
it easier to tell when you are using (or misusing) one, for one thing.

For myself, I also will use all-caps for quasi-constants, ones that are 
set only once, for example from command-line parameters.

In your example,I would not use all-caps for the formal parameter in the 
function  definition.  I would have written

def build_product_prices_dictionary(workbook_definitions:dict )->dict:
...
     price_array = xl.iget_array(
         file_name=workbook_definitions[ "file_name" ],

There is no value in making a formal parameter's name be all-caps, since 
even if it were the same string as an actual global parameter, it would 
not mean that actual parameter: it is only a placeholder.  There could 
even be a negative consequence, because later you might forget and think 
that the formal parameter's name meant that the global parameter would 
be used automatically in the function call, as if it were a default 
parameter.  At a minimum, this could lead to confusion about your 
intent, at a maximum it could end up being a bug.

Perhaps you wrote it that way as a reminder which dict to use.  If so, 
that kind of information would better go into the docstring:

def build_product_prices_dictionary(workbook_definitions:dict) -> dict:
     """Return a dictionary of product prices given their definitions.

     ARGUMENT
     workbook_definitions -- a dict of product definitions, typically
                             the global WORKBOOK_DEFINITIONS.
     """
     # ...

Alternatively, you could make the global be the default for the argument:

def build_product_prices_dictionary(workbook_definitions:dict =
                                     WORKBOOK_DEFINITIONS)->dict:

This might or might not make sense depending on how you plan to use the 
function.

So basically, PyCharm is suggesting that you use a clearer, less 
problem-prone style of naming.  I'd heed the advice.  It would also be 
in line with what many other programmers are used to reading, and that's 
a positive advantage.

On 11/11/2022 3:54 AM, dn wrote:
> PyCharm is warning against using an identifier of all upper-case letters 
> as a function's parameter, saying "Argument name should be lowercase". 
> (weak, code smell)
> 
> 
> The application consists of three+ files:
> - configuration
> - mainline script
> - module of workbook functions
> 
> The mainline reads the configuration parameters to set the application's 
> environment. All of the config/settings are constants. Some of them 
> appear as a dictionary (PRICES_WORKBOOK) defining a workbook's 
> (spreadsheet's) parameters, eg the filename, which work-sheet to use, etc.
> 
> 
> The mainline calls the relevant functions from within the module, 
> as-needed:-
> 
> import prices_workbook as pw
> ...
> product_prices = pw.build_product_prices_dictionary( PRICES_WORKBOOK )
> 
> 
> The module's function definition is:
> 
> def build_product_prices_dictionary( WORKBOOK_DEFINITIONS:dict )->dict:
> ...
>      price_array = xl.iget_array(
>          file_name=WORKBOOK_DEFINITIONS[ "file_name" ],
>          ...
> 
> (the function def is flagged, as above)
> 
> 
> A quick scan of PEP-008 failed to yield anything relevant. Why is this 
> frowned upon as poor Python, or a matter of style?
> 
> Yes, a dict is mutable, but the upper-case denoting a constant indicates 
> that none of its values are to be changed by the programmer.
> 
> As far as the function is concerned, the dict and its contents are 
> constants.
> (but the dict can't be treated as a global ENV[IRONMENT] object, because 
> it has to cross into the module's namespace)
> 
> 
> Is passing the dict as an argument/parameter considered to be 
> incompatible with its designation as a constant?
> 
> Perhaps the style should be more enum-like, ie the dict's name in 
> lower-case, with the key-named in upper case, eg
> 
>      workbook_definitions[ "FILE_NAME" ]
> 
> 
> Am not particularly concerned by the IDE raising this as a 'problem' - 
> will quite happily ignore and carry-on; but am curious as to the logic 
> behind the analysis - and why it doesn't come readily to mind.
> 
> Advice, comments, critique welcome!
>