Should I extract values from Python dictionaries into object attributes?

I have a Python class that is initialized with a dictionary of settings, like this:

def __init__(self, settings):
    self._settings = settings

Settings dictionary contains 50-100 different parameters that are used quite a lot in other methods:

def MakeTea(self):
    te开发者_C百科a = Tea()
    if self._settings['use_sugar']:
        tea.sugar_spoons = self._settings['spoons_of_sugar']
    return tea

What I want to know is whether it makes sense to preload all the params into instance attributes like this:

def __init__(self, settings):
    self._use_sugar = settings['use_sugar']
    self._spoons_of_sugar = settings['spoons_of_sugar']

and use these attributes instead of looking up dictionary values every time I need them:

def MakeTea(self):
    tea = Tea()
    if self._use_sugar:
        tea.sugar_spoons = _self._spoons_of_sugar
    return tea

Now, I am fairly new to Python and I worked mostly with compiled languages where it really is a no-brainer: access to instance fields will be much faster than looking up values from any kind of hashtable-based structure. However, with Python being interpreted and all, I'm not sure that I'll have any significant performance gain because at the moment I have almost no knowledge of how Python interpreter works. For all I know, using attribute name in code may involve using some internal dictionaries of identifiers in interpreted environment, so I gain nothing.

So, the question: are there any significant performance benefits in extracting values from dictionary and putting them in instance attributes? Are there any other benefits or downsides of doing it? What's the good practice?

I strongly believe that this is an engineering decision rather than premature optimization. Also, I'm just curious and trying to write decent Python code, so the question seems valid to me whether I actually need those milliseconds or not.

---

You're comparing attribute access (self.setting) with attribute access (self.settings) plus a dictionary lookup (settings['setting']). Classes are actually implemented as dictionaries, so the problem reduces to two dictionary lookups vs. one. One lookup will be faster.

A simpler and faster way to copy an initialization dict than the one in the other answer is:

class Foobar(object):
    def __init__(self, init_dict):
        self.__dict__.update(init_dict)

However, I wouldn't do this for optimization purposes. It's both premature optimization (you don't know that you have a speed problem, or what your bottleneck is) and a micro-optimization (making an O(n²) algorithm O(n) will make more of a difference than removing an O(1) dictionary lookup from the original algorithm).

If somewhere, you're accessing one of these settings many, many times, just create a local reference to it, rather than polluting the namespace of Foobar instances with tons of settings.

These are two reasonable designs to consider, but you shouldn't choose one or the other for performance reasons. Instead of either one, I would probably create another object:

class Settings(object):
    def __init__(self, init_dict):
        self.__dict__.update(init_dict)

class Foobar(object):
    def __init__(self, init_dict):
        self.settings = Settings(init_dict)

just because I think self.settings.setting is nicer than self.settings['setting'] and it still keeps things organized.

This is a good use for a collections.namedtuple, if you know in advance what all the setting names are.

---

If you put them into the instance attributes then you'll be looking up your instance dictionary... so in the end you're just gonna be doing the same thing. So no real performance gain or loss.

Example:

>>> class Foobar(object):
    def __init__(self, init_dict):
        for arg in init_dict:
            self.__setattr__(arg, init_dict[arg])
>>> foo = Foobar({'foobar': 'barfoo', 'shroobniz': 'foo'})
>>> print(foo.__dict__)
{'foobar': 'barfoo', 'shroobniz': 'foo'}

So if python looks up foo.__dict__ or foo._settings doesn't really make a difference.