As a recent graduate in computer science, I really probably should have known this, but today I learned. This morning as the team and I were discussing some new methods and software to write the discussion came up about what were the
**kwargs we so often see in method declarations within Python. Off to the Internet we went and found a perfect explanation from none other than StackOverflow.
**kwargs are arguments given to a method. Now, we all knew this to be true, this was not the interesting part. The interesting thing to me was that you can put these in your method declarations if you want it to accept varying lengths of arguments rather than explicitly defined ones. Very cool indeed.
Now, I’ve used arguments a lot in computer science especially command line arguments when writing small assignments for classes. I knew these were passed in as
*args but was unsure of what the
**kwargs were. From the StackOverflow answer they are both sets of arguments except the difference is that
*args is an ordered list of values while
**kwargs is a dictionary key-pair or key word arguments. So passing in either a list or a dictionary will allow us to use these variables to allow our methods to take any number of arguments.
Probably should have known that. Probably should have a deeper and better understanding of it. I’m just getting started. You learn something new everyday.
At my job we are currently undergoing a total rewrite of their old web-based data entry system. It’s written in Django and works pretty-alright we are just going to make it better. When it was first written the company was small and very few tests were being done. This caused the initial design to lack foresight into the growth of the project. Another problem with this current system is that it was an almost direct port of their old Microsoft Access version they had been running before. The company is international and a web based system is much better and easier for the employees to use but wasn’t designed with growth in mind.
With a better understanding of how the systemis being used and what the users wanted it to do we have been in the beginning phases of development for about three weeks now. Parts of the site are ready to go live within a week but the major parts are left.
One obstacle that was brought up by one of the software engineers today was the idea of creating a custom generic form that could be reused in various ways throughout the site. The trick was going to be with saving to a dynamic model. Django has few great built-in ways of creating a form based on a model on our MySQL database. The problem is there isn’t an easy way to pass it a model to base the form off of. Theoretically, you should create a model form for each of your models regardless. We felt like we could get more out of writing our own custom generic form though.
To accomplish this hurdle I came across closures. I’d never heard of closures before and if you are in the mood the Wikipedia article does a fine job explaining it. Essentially we were going to use a closure around our generic model form class to pass it any model we pleased.
Following this example from StackOverflow (another example) we came up with something like the following:
model = custom_model
form = generic_model_form(this_model)()
This worked out great. We were able to instantly see the forms generated to our templates using this new way. Unfortunately, we spent so long on this and just thinking about how to generate and save all of these forms that we went completely back to the drawing board with all of the models. I’d rather have simple, easy-to-understand code than overly-generic, complex code. I just found the whole idea of closures, which I believe are similar to lambda expressions which I have used before, very fascinating and we were able to use them, if even just for a moment, today in our daily tasks and creations.
Welcome to my new blog. Created for me to take notes on my every day workings and findings in the areas of web development and computer science. I will try to update regularly with notes that I take each day working on the various projects that I do.
A little about myself, I am a recent graduate of the University of Utah with a Bachelors Degree in Computer Science. I work full-time as the software engineering manager for a textile testing company and do sub-contract work on the side. I created this blog as a place to keep my notes, establish discussion, and learn the tricks of programming and designing WordPress sites.
The site is named Eric Saupe, as that is my name, and the tagline (for now) is Things my wife doesn’t understand. Often while I was at school and coming home from work I would want to tell someone about the cool new things I learned or discovered and my wife, Carly, was always the only one around so I would tell her. She would smile and nod her head but she would often tell me that she has no idea what I’m talking about nor does she care if I’ve created an algorithm to minimize BDD variable lists or found a cool new way to generate and save forms using Django. I needed a place to let my thoughts go and this is what I hope to accomplish with this site.
I hope you come back often and I hope it is as beneficial for you as I hope it will be for me.