Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
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 *args or **kwargs (which are really better options, by the way), you can use the inspect module to do what you're trying to do.
import inspect, collections
def checkif_paramcomboexists(numpeople, numreviews, prophunters,
utility_funcform, goods):
...
temp = inspect.getargvalues(inspect.currentframe())
args = temp[0]
valuedict = temp[-1]
ordered_args_dict = collections.OrderedDict(sorted(valuedict.items(), key=lambda x: args.index(x[0])))
paramvalues = ordered_args_dict.values()
...
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 OrderedDict that 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 with ordered_args_dict.values(), which will give you the output you're looking for for paramvalues: a properly ordered list of the arguments, no matter what the name is.
This situation really calls for an object. You are duplicating what is essentially instance information about a specific database table in 2 places, so it would make sense to make both these functions in to methods of some sort of database table interface object that has a tablecols attribute, then use self.tablecols in both methods.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Assume two functions, where you do it by default value of function,
def foo_def(name = "Default Name" , age = 10) :
print (f"my name is {name} and I am {age}.")
and just take kwargs, but maybe check it later
def foo_kwargs(**kwargs) :
name = kwargs.get('name') if kwargs.get('name') != None else "Default Name"
age = kwargs.get('age') if kwargs.get('age') != None else 10
print (f"my name is {name} and I am {age}.")
Now in my "opinion" for sure the first code has higher readability, and for usage of typing it's probably much favored way of coding, although this probably falls in "opinion" category.
Now my question is :
Are there actual behavior difference? for example, if I'm basically 'for sure' that this code will not be maintained by anyone else and will be kept short, is it fine to code like foo_kwargs? Is there any risk of unexpected behavior by using **kwargs instead of having it has an actual argument?
Is **kwarg basically only meant for exceptional case such as decorators?
What's the main purpose of having **kwargs in normal cases? is there any practical difference in having actual dict object passed as option argument vs using **kwargs?
Some of this question may look quite opinion based, but I'm curious if it's actually "opinion" based (please let me know, if so), or there's some hidden risk / behavior difference so one method is probably strictly better/recommended than the other.
There is a very big behavioral difference, and that's how they handle positional and extra arguments. Consider:
def f_normal(a, b):
return (a, b)
def f_kwargs(**kwargs):
return (kwargs["a"], kwargs["b"])
f_normal(1, 2) # can use positional arguments as well
f_normal(name = 1, age = 2, extra = 3) # unexpected keyword argument
f_kwargs(1, 2) # this doesn't work
f_kwargs(name = 1, age = 2, extra = 3) # extra parameter ignored
In addition, having the accepted parameter names in the parameter list directly gives more power to language analysis features, such as VSCode displaying function signatures when hovering over a function call. The main purpose of **kwargs is for when you want to accept any keyword argument, and you don't know the names beforehand, such as the dict constructor:
dict(a=1, b=2) # {"a": 1, "b": 2}
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
Easy question, is it possible to remove an object from memory and setting all remaining pointers to it to undefined?
You cannot explicitly free memory in Python.
If you want to call del x without having other references to x preventing it from getting garbage collected, you may want to check out weakrefs.
In case you are looking to create some sort of 'cancelable' object that can be invalidated and cause all subsequent attempts to use it to get either a None value or an error, you can do that (after a fashion), but your code will have to be disciplined not to get a direct reference ever, but always refer to the object in a special way, for example:
class deletable(object):
def __init__(self, value):
self.v = value
def destroy(self):
if hasattr(self,"v"): delattr(self, "v")
# create instance
x = deletable( { "key" : "value", "other" : 13 } )
# access
print (x.v["key"])
# re-assign
x.v = { "another" : "dict" }
# "destroy" - option 1 - trigger error on use
x.destroy()
# "destroy" - option 2 - make it None (free memory, but keep x.v valid)
x.v = None # or x.v = {}, if you want to keep it with the original data type of dict()
Now, this "works" on the condition that you never (EVER) do z = x.v and always pass around x as a whole.
(If you know in advance the data type and it is always the same, e.g., dict, you can do a bit better and have the custom object respond to things like x["key"], x.update(some_dict), etc., i.e., look like a regular dict, but still able to call x.destroy() and make it fail further attempts to access. Advanced stuff, I won't write a whole article here on this, not even knowing that I made a correct guess as to what you really need).
For a set of games I'm creating I have a line a code that allows a question to be answered only once. If it has been answered, it adds points to a player's score (the code below sits inside of an if function that checks the answer) and then shuts off the ability to answer the question again. Here's the code I'm currently using:
while self.game1_question1_not_answered:
self.game1_player1_score += self.score_increment
self.game1_question1_not_answered = False`
I would like to use the 'game1' in the code as a generic identifier that can be used to identify any one of the multiple games I'm creating. I tried using a variable called game_name (e.g., game_name = game1) and inserting the variable into the code using an eval function but haven't gotten the code to work. In addition, I realize the eval function has some security concerns. What function could I use to get this to work? The code I've tried that doesn't work looks like this:
while eval('self.' + game_name + 'question1_not_answered'):
eval('self.' + game_name + 'player1_score') += self.score_increment
eval('self.' + game_name + 'question1_not_answered') = False
Is there another function I could use instead of eval to get this to work?
You should use a dict instead. That will allow you to create dynamically-named variables, as it were, to store that information.
self.game_dict = {}
self.game_dict[game_name + 'question1_not_answered'] = True
Then you can modify it as above, and access it in a couple ways:
>>> game_obj.game_dict.get(game_name + 'question1_not_answered')
True
>>> game_obj.game_dict[game_name + 'question1_not_answered']
True
But as jonrsharpe said, your variable names should not include data. The best solution would be to make multiple game objects, each with variables like question1_not_answered. Then if you need to, assign all of those objects to variables in whatever self is in this case.
I'd actually follow #jonrsharpe's comment, but if you really need to have them in one instance, you can use getattr and setattr builtins:
game_name = "game1"
question1_na_line = "{}_question1_not_answered"
player1_sc_line = "{}_player1_score"
question1_na = question1_na_line.format(game_name)
player1_sc = player1_sc_line.format(game_name)
while getattr(self, question1_na):
setattr(self,
player1_sc,
getattr(self, player1_sc) + self.score_increment)
setattr(self, question1_na, False)
The usual way to access attributes by name is the getattr(obj, name) function. Now given the more specific problem you describe I think you'd be better using a dict (or dict of dicts etc) to store your games states (scores etc).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to get your feedback on which of the two snippets is the more pythonic way to handle a lookup.
I'm developing a wrapper for an XML File. I'm loading the XML file, parsing it, store the content in a dictionary and then allow the access through a class method.
Specifically - if the a given returns no result, should I return None or raise an (Key)Error?
I'm a bit confused, because some people suggested me to throw an Error instead of returning an empty value. They said it would be easier and clearer to handle then the error no a higher level.
This is a simplified version of the code:
class NoResult(KeyError):
pass
class Wrapper(object):
....
self.my_dict = {}
....
get_Entity(self, id):
if id in self.my_dict:
value = self.my_dict[id]
return value
else:
return None
class Wrapper(object):
....
self.my_dict = {}
....
get_Entity(self, id):
if id in self.my_dict:
value = self.my_dict[id]
return value
else:
throw NoResult
I would really appreciate your thoughts!
The latter matches what you would expect with standard Python types, and can be simplified to:
def get_Entity(self, id):
return self.my_dict[id]
This will raise the KeyError for you if id isn't in self.my_dict. Getting an error tells the calling function that what was expected to be in the dictionary wasn't - quietly returning None leaves you open to subtle bugs later (unless you immediately check if val is None, in which case you could have used try anyway).
(The other version can also be simplified, to:
def get_Entity(self, id):
return self.my_dict.get(id)
).
dict already contains the 2 behaviors. (get -> None and [] -> KeyError).
Also, None is a valid value for a dict:
my_dict = {'key': None}
my_dict['key']
# Returns None
Ok, this will be a little bit generic but looks at the expectations of the programmer using your library. If I am doing a lookup in an XML file I am probably expecting that I will get a result.
Lets say I am then a lazy programmer who does no validation of what you return to me and try and use it. If you return to me a special none value my code will continue to run and will encounter an error later and it may not be obvious to me that that is the root cause.
On the other hand if you threw an exception as soon as I requested the invalid value my program would crash immediately and give me an accurate explanation of what went wrong.
If programmers all did careful validation on what your library returns either way will work fine but lazier (read most :P) programmers will likely not do so, thus the exception route will provide the least surprise and confusion. As a library you never want to surprise or confuse your user when avoidable so I would go for the exception route.
However I shall quickly note, if doing an invalid lookup is a 'normal' action in your libraries work-flow you can more reasonably expect programmers to check so then either becomes reasonable.
Remember the rule of thumb, use an exception when the action is actually exceptional and surprising, otherwise ymmv but you probably dont have to.
I want a function that can return the variable/object name as str like this :
def get_variable_name (input_variable):
## some codes
>>get_variable_name(a)
'a'
>>get_variable_name(mylist)
'mylist'
it looks like silly but i need the function to construct expression regarding to the variable for later on 'exec()'. Can someone help on how to write the 'get_variable_name' ?
I've seen a few variants on this kind of question several times on SO now. The answer is don't. Learn to use a dict anytime you need association between names and objects. You will thank yourself for this later.
In answer to the question "How can my code discover the name of an object?", here's a quote from Fredrik Lundh (on comp.lang.python):
The same way as you get the name of that cat you found on your porch:
the cat (object) itself cannot tell you its name, and it doesn’t
really care — so the only way to find out what it’s called is to ask
all your neighbours (namespaces) if it’s their cat (object)…
….and don’t be surprised if you’ll find that it’s known by many names,
or no name at all!
Note: It is technically possible to get a list of the names which are bound to an object, at least in CPython implementation. If you're interested to see that demonstrated, see the usage of the inspect module shown in my answer here:
Can an object inspect the name of the variable it's been assigned to?
This technique should only be used in some crazy debugging session, don't use anything like this in your design.
In general it is not possible. When you pass something to a function, you are passing the object, not the name. The same object can have many names or no names. What is the function supposed to do if you call get_variable_name(37)? You should think about why you want to do this, and try to find another way to accomplish your real task.
Edit: If you want get_variable_name(37) to return 37, then if you do a=37 and then do get_variable_name(a), that will also return 37. Once inside the function, it has no way of knowing what the object's "name" was outside.
def getvariablename(vara):
for k in globals():
if globals()[k] == vara:
return k
return str(vara)
may work in some instance ...but very subject to breakage... and I would basically never use it in any kind of production code...
basically I cant think of any good reason to do this ... and about a million not to
Here's a good start, depending on the Python version and runtime you might have to tweak a little. Put a break point and spend sometime to understand the structure of inspect.currentframe()
import inspect
def vprint(v):
v_name = inspect.currentframe().f_back.f_code.co_names[3]
print(f"{v_name} ==> {v}")
if __name__ == '__main__':
x = 15
vprint(x)
will produce
x ==> 15
if you just want to return the name of a variable selected based on user input... so they can keep track of their input, add a variable name in the code as they make selections in addition to the values generated from their selections. for example:
temp = raw_input('Do you want a hot drink? Type yes or no. ')
size = raw_input('Do you want a large drink? Type yes or no. ')
if temp and size == 'yes':
drink = HL
name = 'Large cafe au lait'
if temp and size != 'yes':
drink = CS
name = 'Small ice coffee'
print 'You ordered a ', name, '.'
MJ
If your statement to be used in exec() is something like this
a = ["ddd","dfd","444"]
then do something like this
exec('b = a = ["ddd","dfd","444"]')
now you can use 'b' in your code to get a handle on 'a'.
Perhaps you can use traceback.extract_stack() to get the call stack, then extract the variable name(s) from the entry?
def getVarName(a):
stack = extract_stack()
print(stack.pop(-2)[3])
bob = 5
getVarName(bob);
Output:
getVarName(bob)