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!
--
https://mail.python.org/mailman/listinfo/python-list
