I am trying to improve my program so that it conforms to good programming
practices. So I am looking for suggestions on whether the way I have programmed
something is a good way of doing it.
I have a module called dbfunctions.py in which I have defined:
dbparams = {
'dbname': 'qualitysimparams',
'tablename': 'qualityparams',
'tablecols': ('numpeople', 'numreviews', 'prophunters',
'utility_funcform', 'goods'
)
and a function:
def obtainid_ifrecord(dbname, tablename, tablecols, values):
'''Checks if there already exists a record with given <values>.
If so, returns the id of that record, otherwise returns zero.'''
con, c = connecttodb()
q1 = "use {0}".format(dbname)
c.execute(q1)
q2p1 = "select id from {0} ".format(tablename)
q2p2 = "where " + " = %s and ".join(tablecols) + " = %s"
q2 = q2p1 + q2p2
c.execute(q2, values)
res = c.fetchall()
c.close()
con.close()
if res:
return res[-1][0]
else:
return 0
There are other functions and variables in addition to the above two, but
they are not relevant for this post.
In another file I have a function:
def checkif_paramcomboexists(numpeople, numreviews, prophunters,
utility_funcform, goods):
'''Check in the database if the simulation has been run with the
specified parameters. If so return the id of that run.
'''
goodsjson = sjson.dumps(goods)
# paramvalues: in same order as listed in dbf.dbparams['tablecols']
paramvalues = (numpeople, numreviews, prophunters,
utility_funcform, goodsjson)
id = dbf.obtainid_ifrecord(dbf.dbparams['dbname'],
dbf.dbparams['tablename'],
dbf.dbparams['tablecols'],
paramvalues)
return id
It seems to me that the fact that hardcoding the variable names in the
paramvalues variable in function checkif_paramcomboexists is not a good practice.
If later I change the order of variables in dbfunctions.dbparams[‘tablecols’] for any
reason, checkif_paramcomboexists function will fail (and can fail silently depending
on the data types). One way to get around this is to define:
paramvalues = [eval(x) for x in dbf.dbparams['tablecols']]
But I have heard that generally it is a bad practice to use eval (although I do not know
why and when it is okay to use it). My questions are:
(i) Is it okay the way I have coded this in regards to the concern I have? I think the answer
is ‘No’, but just want to check with the experts here.
(ii) Is use of eval as I have indicated an acceptable solution?
(iii) If answer to (ii) is ‘no’, what is the alternative?
Thank you for reading through this.
You’re right about the hardcoding not being great, and definitely stay away from
eval. If you don’t want to use*argsor**kwargs(which are really better options, by the way), you can use theinspectmodule to do what you’re trying to do.Basically, what’s going on here is that
inspect.getargvalues(inspect.currentframe())gets you an object where the first item is a properly ordered list of the argument names and the last item is a dictionary of the argument names and values. We then create an ordered dictionary by grabbing the argument name/value mapping from the dictionary, and ordering it based on the list order.What you end up with is an
OrderedDictthat has all of the arguments with their values, but also has them in the right order. That way, you can still choose to refer to them by name (e.g.,ordered_args_dict['numpeople']), but if you can still get all the values in order as you wanted withordered_args_dict.values(), which will give you the output you’re looking for forparamvalues: a properly ordered list of the arguments, no matter what the name is.