String representation and pretty printing as in NIXPy

[achilleas-k]

String representations (__str__ and __repr__) should be the same in odML as in NIXPy. The objects should behave in the same way so they should also look the same.

It would also be nice to port over the pretty printing function (pprint()).

This is related to #67 but I didn't want to bring it into that old discussion because it's more general.

This issue is also related to #307.

[mpsonntag]

One point to make is, that the objects are not exactly the same and will probably never be, so it might be good to have an easy way to spot the difference between a nix and an odml odml object.
That said having the pprint() function in odml is definitely a good thing and I would also be all in for having __str__ and __repr__ be as similar as possible, maybe with a distinction in odml. Currently the formats look like this:

nix:

• Section: Section: {name = sec, type = sectype, id = 1e2u...}
• Property: Property: {name = prop}

odml:

• Section: <Section name[type] (0)>
• Property: <Property propname>

A couple of points here:

• I like the verboseness of nix
• I also like the pointer in odml sections how many subsections they contain

I'd probably vote for the nix style of formatting while including subsection numbers in addition.

[achilleas-k]

Showing child counts is what we discussed (extensively) in #67 and never landed on a solution.

For distinguishing, we could simply outright state the namespace:
nix.Section: {name = sec, type = sectype, id = 1e2u...}
odml.Section: {name = sec, type = sectype, id = 1e2u...}

[mpsonntag]

As a simple solution for counts I'd go for odml.Section[4/2]: {...} where 0/2 are the immediate child sections (4) and properties (2). I read up bit on #67 and I don't think it is misleading, since as soon as anyone does sec.sections the printout will show exactly four sections and display the number of their immediate child sections and properties as well. In my point of view having a bit of information is better than having no information when navigating on the command line and since #67 is open since over a year, maybe an easy solution is the better option. The outcome of discussion #67 can be realised via pprint() when a user specifically asks for it.

[achilleas-k]

I'm not against showing direct descendants, only.