views:

256

answers:

7

I'm new to Python, and am sort of surprised I cannot do this.

dictionary = {
    'a' : '123',
    'b' : dictionary['a'] + '456'
}

I'm wondering what the Pythonic way to correctly do this in my script, because I feel like I'm not the only one that has tried to do this.

EDIT: Enough people were wondering what I'm doing with this, so here are more details for my use cases. Lets say I want to keep dictionary objects to hold file system paths. The paths are relative to other values in the dictionary. For example, this is what one of my dictionaries may look like.

dictionary = {
    'user': 'gnucom',
    'home': '/home/' + dictionary['user']
}

It is important that at any point in time I may change dictionary['user'] and have all of the dictionaries values reflect the change. Again, this is an example of what I'm using it for, so I hope that it conveys my goal.

From my own research I think I will need to implement a class to do this.

+3  A: 
>>> dictionary = {
... 'a':'123'
... }
>>> dictionary['b'] = dictionary['a'] + '456'
>>> dictionary
{'a': '123', 'b': '123456'}

It works fine but when you're trying to use dictionary it hasn't been defined yet (because it has to evaluate that literal dictionary first).

But be careful because this assigns to the key of 'b' the value referenced by the key of 'a' at the time of assignment and is not going to do the lookup every time. If that is what you are looking for, it's possible but with more work.

Daniel DiPaolo
That might start to look yucky after a few hundred entries....
gnucom
You could use `dictionary.update({'b': dictionary['a'] + '456'})` and pass in as big of a dictionary as you want, but it sounds like g.d.d.c has the approach you want, which is truly self-referential and dynamic lookup and not just "at-assignment-time" lookup.
Daniel DiPaolo
Thanks for the info. That may be what I end up doing, because we have Python 2.4 installed by default.
gnucom
@gnucom: python 2.4 is quite old, the current version is 2.7, and all the real effort is focused on 3. You should seriously try to upgrade.
Daenyth
+1  A: 

Nearest I came up without doing object:

dictionary = {
    'user' : 'gnucom',
    'home' : lambda:'/home/'+dictionary['user'] 
}

print dictionary['home']()
dictionary['user']='tony'
print dictionary['home']()
Tony Veijalainen
+10  A: 

No fear of creating new classes - You can take advantage of Python's string formating capabilities and simply do:

class MyDict(dict):
   def __getitem__(self, item):
       return dict.__getitem__(self, item) % self

dictionary = MyDict({

    'user' : 'gnucom',
    'home' : '/home/%(user)s',
    'bin' : '%(home)s/bin' 
})


print dictionary["home"]
print dictionary["bin"]
jsbueno
Are those "% dictionary" in the print statements an accidental oversight? They shouldn't be needed.
Roger Pate
+1 Good idea. I didn't think to do it this way.
gnucom
In the strictest since this *is* creating a new class, although it's a derived one...and nevertheless extremely clever IMHO and almost transparent in most respects (another good thing).
martineau
@Martineau: I know this is reating a new class, and this is what I meant - it was a response to Tony Veijalainen's answer (bellow) which was avoiding creating a new class.
jsbueno
@Roger - indeed - someone corrected it for me already.
jsbueno
This class could be made into a kind of mini python-based-spreadsheet and be able to do much more than just text substitution and string concatenation by changing the return value of `__getitem__()` to something like `eval(dict.__getitem__(self, item) % self, globals())`. Of course for safety you'd probably want to restrict what's in the dictionary argument passed and not really use globals() which has all the builtins in it.
martineau
+1  A: 

Write a class, maybe something with properties:

class PathInfo(object):
    def __init__(self, user):
        self.user = user

    @property
    def home(self):
        return '/home/' + self.user

p = PathInfo('thc')
print p.home # /home/thc 
THC4k
+2  A: 

What you're describing in your edit is how an INI config file works. Python does have a built in library called ConfigParser which should work for what you're describing.

Greg
+1  A: 

This is an interesting problem. It seems like Greg has a good solution. But that's no fun ;)

jsbueno as a very elegant solution but that only applies to strings (as you requested).

The trick to a 'general' self referential dictionary is to use a surrogate object. It takes a few (understatement) lines of code to pull off, but the usage is about what you want:

S = SurrogateDict(AdditionSurrogateDictEntry)
d = S.resolve({'user': 'gnucom',
               'home': '/home/' + S['user'],
               'config': [S['home'] + '/.emacs', S['home'] + '/.bashrc']})

The code to make that happen is not nearly so short. It lives in three classes:

import abc

class SurrogateDictEntry(object):
    __metaclass__ = abc.ABCMeta
    def __init__(self, key):
        """record the key on the real dictionary that this will resolve to a 
           value for
        """
        self.key = key

    def resolve(self, d):
        """ return the actual value"""
        if hasattr(self, 'op'):
            # any operation done on self will store it's name in self.op. 
            # if this is set, resolve it by calling the appropriate method 
            # now that we can get self.value out of d
            self.value = d[self.key]
            return getattr(self, self.op + 'resolve__')()
        else:
            return d[self.key]

    @staticmethod
    def make_op(opname):
        """A convience class. This will be the form of all op hooks for subclasses
           The actual logic for the op is in __op__resolve__ (e.g. __add__resolve__)
        """
        def op(self, other):
            self.stored_value = other
            self.op = opname
            return self
        op.__name__ = opname
        return op

Next, comes the concrete class. simple enough.

class AdditionSurrogateDictEntry(SurrogateDictEntry):

    __add__ = SurrogateDictEntry.make_op('__add__')
    __radd__ = SurrogateDictEntry.make_op('__radd__')

    def __add__resolve__(self):
        return self.value + self.stored_value 

    def __radd__resolve__(self):
        return self.stored_value + self.value

Here's the final class

class SurrogateDict(object):
    def __init__(self, EntryClass):
        self.EntryClass = EntryClass

    def __getitem__(self, key):
        """record the key and return""" 
        return self.EntryClass(key)

    @staticmethod
    def resolve(d):
        """I eat generators resolve self references"""
        stack = [d]
        while stack:
            cur = stack.pop()
            # This just tries to set it to an appropriate iterable
            it = xrange(len(cur)) if not hasattr(cur, 'keys') else cur.keys()
            for key in it:
                # sorry for being a duche. Just register your class with
                # SurrogateDictEntry and you can pass whatever.
                while isinstance(cur[key], SurrogateDictEntry):
                    cur[key] = cur[key].resolve(d)
                # I'm just going to check for iter but you can add other
                # checks here for items that we should loop over. 
                if hasattr(cur[key], '__iter__'):
                    stack.append(cur[key])
        return d

In response to gnucoms's question about why I named the classes the way that I did.

The word surrogate is generally associated with standing in for something else so it seemed appropriate because that's what the SurrogateDict class does: an instance replaces the 'self' references in a dictionary literal. That being said, (other than just being straight up stupid sometimes) naming is probably one of the hardest things for me about coding. If you (or anyone else) can suggest a better name, I'm all ears.

I'll provide a brief explanation. Throughout S refers to an instance of SurrogateDict and d is the real dictionary.

  1. A reference S[key] triggers S.__getitem__ and SurrogateDictEntry(key) to be placed in the d.

  2. When S[key] = SurrogateDictEntry(key) is constructed, it stores key. This will be the key into d for the value that this entry of SurrogateDictEntry is acting as a surrogate for.

  3. After S[key] is returned, it is either entered into the d, or has some operation(s) performed on it. If an operation is performed on it, it triggers the relative __op__ method which simple stores the value that the operation is performed on and the name of the operation and then returns itself. We can't actually resolve the operation because d hasn't been constructed yet.

  4. After d is constructed, it is passed to S.resolve. This method loops through d finding any instances of SurrogateDictEntry and replacing them with the result of calling the resolve method on the instance.

  5. The SurrogateDictEntry.resolve method receives the now constructed d as an argument and can use the value of key that it stored at construction time to get the value that it is acting as a surrogate for. If an operation was performed on it after creation, the op attribute will have been set with the name of the operation that was performed. If the class has a __op__ method, then it has a __op__resolve__ method with the actual logic that would normally be in the __op__ method. So now we have the logic (self.op__resolve) and all necessary values (self.value, self.stored_value) to finally get the real value of d[key]. So we return that which step 4 places in the dictionary.

  6. finally the SurrogateDict.resolve method returns d with all references resolved.

That'a a rough sketch. If you have any more questions, feel free to ask.

aaronasterling
Very impressive I like this. :)
gnucom
Can you possibly discuss why you named your classes the way you did? I'm trying to develop a thorough understanding of the class and, well, I don't understand every part of your code. :P
gnucom
@gnucom, updated the bottom of my post. HTH. feel free to ask any questions if something is tripping you up. It's a little fragile right now. In particular, `L[foo] + 4 + 4` might fail. `L[3] + L[3] + 1` works though. I'm not sure about `1 + L[3] + l` but I think that that would fail. The two (alleged) failures could be corrected by having `SurrogateDictEntry` implement an operation stack instead of just storing one operation/value pair.
aaronasterling
@gnucom Also don't get too infatuated with this solution. The two that I linked to are __much__ better for your use-case. I mainly did it just to do it.
aaronasterling
@Aaron, Just an interesting solution to the problem that's all. :)
gnucom
+1  A: 

As sort of an extended version of @Tony's answer, you could build a dictionary subclass that calls its values if they are callables:

class CallingDict(dict):
    """Returns the result rather than the value of referenced callables.

    >>> cd = CallingDict({1: "One", 2: "Two", 'fsh': "Fish",
    ...                   "rhyme": lambda d: ' '.join((d[1], d['fsh'],
    ...                                                d[2], d['fsh']))})
    >>> cd["rhyme"]
    'One Fish Two Fish'
    >>> cd[1] = 'Red'
    >>> cd[2] = 'Blue'
    >>> cd["rhyme"]
    'Red Fish Blue Fish'
    """
    def __getitem__(self, item):
        it = super(CallingDict, self).__getitem__(item)
        if callable(it):
            return it(self)
        else:
            return it

Of course this would only be usable if you're not actually going to store callables as values. If you need to be able to do that, you could wrap the lambda declaration in a function that adds some attribute to the resulting lambda, and check for it in CallingDict.__getitem__, but at that point it's getting complex, and long-winded, enough that it might just be easier to use a class for your data in the first place.

intuited