jackqu7

Yes, this is possible as long as the second level nested object has a role to stop infinite recursion from occurring. Cycles are not automatically detected.

    class BaseMapper(Mapper):

        __type__ = TestType

        score = Integer()
        nest = Nested('NestedMapper')

        __roles__ = {'nested': blacklist('nest')}

    class NestedMapper(Mapper):

        __type__ = TestType

        back = Nested('BaseMapper', role='nested')
        name = String()

    obj2 = TestType(name='test')
    obj = TestType(score=5, nest=obj2)
    obj2.back = obj

    >> BaseMapper(obj=obj).serialize()
    {'nest': {'back': {'score': 5}, 'name': 'test'}, 'score': 5}

(I'm Jack, another developer at OSL.)

We started writing Kim around the same time as the Marshmallow project began as we found it wasn't suitable for our needs at that time, though it has come a long way since then.

They are very similar projects and have similar functionality, but Kim has a focus on making it relatively simple to do unusual or 'advanced' things.

For example, Kim supports polymorphism out of the box, if you have an AnimalMapper subclassed by a CatMapper and a DogMapper, passing a Cat and a Dog to AnimalMapper.many.serialize() will automatically do the right thing in a similar way to SQLAlchemy polymorphism.

We also have support for complex requirements such as nesting the same object to itself (useful when your JSON representation is nested but your DB representation is flat,) serialising multiple object fields to a single JSON field (eg full_name consisting of obj.first_name and obj.last_name,) a range of security models for marshalling nested objects and a fairly extensible roles system.

In general we've followed the philosophy "Simple things should be simple. Complex things should be possible."

Magic 1 was what inspired me to start the project, I continue to be in awe at the ambition of Bill's project. Watch this space for a more technically focused post.

Completely agree, this was just the first foray into documenting this project and I wanted to make it less heavy on the details of the hardware to reach a wider audience. I'm definitely going to put up a more technical post and the sources/schematics as soon as I can.

To answer your questions, it's hard wired with the control logic made out of the simpler chips (7400, 7408, 7432 etc) but the rest of the system does contain more complex chips, the 74181 ALUs being the largest.

This is really interesting, but I wonder if there is any support for user authentication? Perhaps by combining with basic auth?

In terms of starting actual development, rather than the whole process from conception onwards:

1. Define DB schema

2. Define URLs. I find this is the best way to figure out what bits I actually need to write

3. Solve any difficult/tricky bits first, even if just as a proof of concept

4. Implement the rest

Why do I have to sign up to start using this? I think people would be more likely to try it if they didn't have to cross that barrier.

You should have it so using it on one machine just works and requires no signup, then have an option to add a user/pass at a later stage.