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).
Related
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 1 year ago.
Improve this question
I'm currently writing an agent function that is designed to compete in competition and will get called every turn to perform a series of moves. There is data that I'd like to save between turns (calls of the function).
My question is what is the best way to store this data so that my function can access it between calls without having to recompute it every call. I was thinking about making a global class object that would store everything I needed, but suspected there might be other ways.
To give an example, let's say I want to store a long list that took a bit of time to compute inside that function, where can I put/store that list so that I can access it again the next time the function is called, without having to recompute it.
There are two straightforward solutions, if I understand the question correctly. You can use a closure--an inner function--so you can do your preprocessing of your data and return a function that has access to it in its scope.
Here, with a rather silly example of an accumulated sum that you can initialise when you create the closure:
def make_acc_sum(init_elements):
# initial preprocessing
s = sum(init_elements)
# function that knows the preprocessed data
def acc_sum(new_val):
nonlocal s
s += new_val
return s
return acc_sum
ac = make_acc_sum([1, 2, 3])
for i in range(5):
print(ac(i))
This is a fine technique in many applications, when you don't want to do too much with the data in the enclosing scope. If you just want to access it when invoking a function and nothing more, it can handle your needs.
If you want your "function" to support more general manipulation of your pre-processed data, you can turn it into an object. Objects from a class that implements __call__ can be called just as functions can:
class acc_sum:
def __init__(self, init_elements):
# initial preprocessing
self.s = sum(init_elements)
def __call__(self, new_val):
# function that knows the preprocessed data
self.s += new_val
return self.s
ac = acc_sum([1, 2, 3])
for i in range(5):
print(ac(i))
but this version of ac is still an object that can have attributes and additional methods on it, so you can do more with it than you can with a plain closure (even though the example doesn't exploit that).
You seem to be onto the right track. Why not create an object class, make instances of it to store different 'save data', and see how it goes?
class saveFile:
def __init__(self, data):
self.data = data
def main():
data = something.compute() #whatever that took a bit of time to compute...
#create an instance of a saveFile class object
file_1 = saveFile(data)
#to recall the data in the form of file_1.data
print(file_1.data)
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 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 4 years ago.
Improve this question
I am trying to anonymize accession numbers with a fake custom AN with pydicom:
def an_callback(ds, data_element):
if data_element.tag == Tag(0x00080050):
data_element.value = '0000000000'
ds.walk(an_callback)
I would like to pass a custom value instead of '0000000' to the call back function. I suppose I could use a global variable, but I would like to avoid that to reduce unwarranted bugs. Is there a different way that does not use global variables?
edit: I thought walk was a special python function, but it was just a method of ds, here is the code. You can change the code here for callback to also include an optional parameter. callback(self, data_element, replace_value=None)
def walk(self, callback, recursive=True):
"""Iterate through the DataElements and run `callback` on each.
Visit all DataElements, possibly recursing into sequences and their
datasets. The callback function is called for each DataElement
(including SQ element). Can be used to perform an operation on certain
types of DataElements. E.g., `remove_private_tags`() finds all private
tags and deletes them. DataElement`s will come back in DICOM order (by
increasing tag number within their dataset).
Parameters
----------
callback
A callable that takes two arguments:
* a Dataset
* a DataElement belonging to that Dataset
recursive : bool
Flag to indicate whether to recurse into Sequences.
"""
taglist = sorted(self.keys())
for tag in taglist:
with tag_in_exception(tag):
data_element = self[tag]
callback(self, data_element) # self = this Dataset
# 'tag in self' below needed in case callback deleted
# data_element
if recursive and tag in self and data_element.VR == "SQ":
sequence = data_element.value
for dataset in sequence:
dataset.walk(callback)
A global variable is the simplest solution; if you want to be more elegant, then you could encapsulate the function in some class. Your problem refers to plain Python, so you may want to read Python Alternatives to Global Variables.
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.
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.