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}

That's not a solution as it will not restore the same object graph, it will just repeat values.

One way is to to store a table of objects (as identified by id()) encountered during serialization, indexed by the order you encounter them. If you encounter an object you have already serialized, serialize an index into that table. On deserialization, construct the same kind of table, and deserialize an index with a reference to the same object.

See e.g. AMF for an example format that does this: https://en.wikipedia.org/wiki/Action_Message_Format

The output isn't clear to me:

    {'nest': {'back': {'score': 5}, 'name': 'test'}, 'score': 5}

How can this be mapped back unambiguously to a cyclic structure?

(I might be wrong but it seems to me that the act of serialization has simply expanded the cycle one level deep.)

(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."

I've been saddened by Marshmallow on many occasions (I have gripes with the particular way defaults/validation play together. This is true for WTForms too).

I'm excited to try out Kim. I've been very close to just writing my own serialization lib on many occasions.

It looks like your pipelines might bring a bit of sanity to it. :)

It looks like you support a few sorts of validation, but the docs aren't super clear as to what the expected validation strategy is. Could you elaborate on what that looks like?

My typical strategy I'd like to do is to just a list of functions that take the input and return a boolean as far as validation goes.

Hey that's really great to hear. (that you're keen to use Kim) WTF-Forms and Marshmallow both solve problems and they do it well but it seems like us you wanted something that offered just a bit more flexibility. That's totally the idea behind pipelines in Kim. They are like tiny little computer programmes and are really capable of anything (providing it's possible in Python of course :D )

It's great you asked this question as we noticed part of the documentation was actually broken. here's a link to a pretty basic example of adding extra validation "pipes" to a pipeline

http://kim.readthedocs.io/en/latest/user/advanced.html#custo...

We'd be more than happy to discuss how to solve more complex requirements if there's something specific you had in mind though.

Thanks for the message!

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.

It awed me as well. Plus, the performance and such gave me inspiration that homebrew might be an answer to non-subverted computers post-Snowden. At least, for the bootstrapping phase of other computers, SCM/builds, or key storage.

Only thing was that a HW guy told me the TTL chips he used might be hard to come by. I looked them up and had trouble finding them. So, rather than cloned, the next Magic 1 should be ported use components currently available... preferably 10 year horizon. Also, ideally something fabbed at 0.35 microns or above for visual inspection. Plus realism, as we're practically cheating if you're using deep submicron for "hand-built, old-school" systems.

What kind of primitive components are you using or found consistently available?

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?

Sure, there is. You should read slides by agentzh:

http://agentzh.org/misc/slides/nginx-conf-scripting/

http://agentzh.org/misc/slides/recent-dev-nginx-conf/

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

4.a) Implement 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.

agreed. you could use a cookie/ip or something initially to set the user account