Thoughts on object representation in a dictionary

Discussion in 'Python' started by py, Dec 9, 2005.

  1. py

    py Guest

    Say I have classes which represent parts of a car such as Engine, Body,
    etc. Now I want to represent a Car in a nested dictionary like...

    {string_id:{engine_id:engine_object, body_id:body_object}}....ok?

    Well the other thing is that I am allowed to store strings in this
    dictionary...so I can't just store the Engine and Body object and later
    use them. ....this is just a requirement (which i dont understand
    either)...but its what I have to do.

    So my question is there a good way of storing this information in a
    nested dictionary such that if I receive this dictionary I could easily
    pull it apart and create Engine and Body objects with the information?
    Any suggestions at all? keep in mind I am limited to using a
    dictionary of strings...thats it.

    Thanks for any input.
     
    py, Dec 9, 2005
    #1
    1. Advertising

  2. py

    Peter Hansen Guest

    py wrote:
    ....
    > Well the other thing is that I am allowed to store strings in this
    > dictionary...so I can't just store the Engine and Body object and later
    > use them. ....this is just a requirement (which i dont understand
    > either)...but its what I have to do.


    Homework?

    > So my question is there a good way of storing this information in a
    > nested dictionary such that if I receive this dictionary I could easily
    > pull it apart and create Engine and Body objects with the information?
    > Any suggestions at all? keep in mind I am limited to using a
    > dictionary of strings...thats it.


    You're describing a task that is named "serialization". Google for
    "python serialization" and you'll get lots of useful and interesting
    background to help you out.

    -Peter
     
    Peter Hansen, Dec 9, 2005
    #2
    1. Advertising

  3. On Fri, 09 Dec 2005 11:37:30 -0800, py wrote:

    > Say I have classes which represent parts of a car such as Engine, Body,
    > etc. Now I want to represent a Car in a nested dictionary like...
    >
    > {string_id:{engine_id:engine_object, body_id:body_object}}....ok?
    >
    > Well the other thing is that I am allowed to store strings in this
    > dictionary...so I can't just store the Engine and Body object and later
    > use them. ....this is just a requirement (which i dont understand
    > either)...but its what I have to do.
    >
    > So my question is there a good way of storing this information in a
    > nested dictionary such that if I receive this dictionary I could easily
    > pull it apart and create Engine and Body objects with the information?
    > Any suggestions at all? keep in mind I am limited to using a
    > dictionary of strings...thats it.



    Cry and beg and hold your breath until you turn blue unless your
    boss/client allows you to store general objects in the dictionary?

    Or at least find out *why* they will only let you store strings in the
    dictionary. If they won't tell you, tell them that it makes the job
    (random big number) harder, which corresponds to costing the client $$$.

    Failing that, perhaps you can pickle the objects before you store them in
    the dictionary, although I daresay that will hit performance *hard*.
    Perhaps use cPickle for speed?

    Another possibility would be to build a light-weight serializer into the
    engine class itself:

    class Engine:
    def __init__(self, data):
    self.initialisation_data = data
    process(data)

    def __repr__(self):
    return "Engine(%s)" % self.initialisation_data
    # can't get more lightweight than that

    engine_object = Engine(data)
    s = repr(engine_object)

    so that eval(s) recreates the engine_object. Do the same for all the other
    classes, and then you don't even need to know what each string means, you
    just eval() it and turns into the right sort of object.


    (If you use eval, make sure you are aware of the security implications.)



    --
    Steven.
     
    Steven D'Aprano, Dec 10, 2005
    #3
  4. py

    Paul Rubin Guest

    "py" <> writes:
    > Well the other thing is that I am allowed to store strings in this
    > dictionary...so I can't just store the Engine and Body object and later
    > use them. ....this is just a requirement (which i dont understand
    > either)...but its what I have to do.


    Probably so that the object store can later be moved offline, with the
    shelve module or DB API or something like that.

    > So my question is there a good way of storing this information in a
    > nested dictionary such that if I receive this dictionary I could easily
    > pull it apart and create Engine and Body objects with the information?
    > Any suggestions at all? keep in mind I am limited to using a
    > dictionary of strings...thats it.


    The spirit of the thing would be serialize the objects, maybe with
    cPickle, as Steven suggests. A kludgy way to thwart the policy
    might be to store the objects in a list instead of a dictionary:
    x[0], x[1], etc. Then have a dictionary mapping keys to subscripts
    in the list. The subscripts would be stringified ints: '0','1',... .
     
    Paul Rubin, Dec 10, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?RGFuIE5hc2g=?=

    dictionary concept - thoughts on how to do plz!

    =?Utf-8?B?RGFuIE5hc2g=?=, Nov 8, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    341
    =?Utf-8?B?RGFuIE5hc2g=?=
    Nov 8, 2004
  2. Ilias Lazaridis
    Replies:
    6
    Views:
    453
    Ilias Lazaridis
    Feb 21, 2006
  3. james_027
    Replies:
    1
    Views:
    336
    Marc 'BlackJack' Rintsch
    Aug 22, 2007
  4. Navkirat Singh
    Replies:
    6
    Views:
    3,157
    Navkirat Singh
    Jul 29, 2010
  5. Chris Rebert
    Replies:
    0
    Views:
    540
    Chris Rebert
    Jul 29, 2010
Loading...

Share This Page