change value related behaviors

[jgrewe]

replacement pr for #236. The following changes have been made:

1. prop.value returns a copy(!) of the value list. Manipulating this list will not affect the content of the property (fixes Usage of python list as odml value circumvents dtype checks #227).
2. implement prop.append, prop.extend methods. The first only for single convertible values, the latter for lists of such as well as other properties. (fixes add append value functionality for properties is verison 1.4 #223)
3. Implement the __setitem__ method for direct value manipulation. Property more or less behaves like a list. Passed values are checked for converability.
4. Implement prop.merge method. This will sync all but the dependency and dependencyValue attributes. ValueErrors are raised, if information is set in both properties but are in conflict. (fixes Add merge functionality on value level #221)
5. add some docstrings
6. some tests

[coveralls]

Coverage increased (+0.4%) to 71.328% when pulling 4667b18 on jgrewe:property into 2830914 on G-Node:master.

[mpsonntag]

This is really nice to use now!

[mpsonntag]

I think this line should be [1, 2, 3, 4] ;)

[jgrewe]

hehe, no, I think this is correct, p.append(4) would change it, p.value.append(4) appends to the copy and not the property

[mpsonntag]

argh sorry, blanked out the .value. part...

[mpsonntag]

I think Property.dtype is currently not reset when resetting the values. Maybe this can be reset here as well.

[jgrewe]

we do have the dtype setter for this. Imho, I would rather not reset it on deleting the value(s)

[JuliaSprenger]

In general I am happy with this implementation, there are just a few cases, where I think the behaviour should be different

• providing a generator as value should list the generated items, not the string version of the generator (eg odml.Property(name='prop', value=range(10)) should contain a list of numbers, not a string)
• The automatic dtype conversion should not introduce a loss of information

    prop1 = odml.Property(name='prop1', value=[3])
    prop2 = odml.Property(name='prop2', value=[3.5])
    prop1.merge(prop2)

should result in an Error rather than prop1.value == [3,3]

Also I suggest to also add a section.extend() function similar to the property.extend() function, buts that's probably a different issue.

[jgrewe]

@JuliaSprenger you can now pass a range or anything that defines __next__ or __iter__ as value.
Further, merge. extend and append got a strict option that by default raises ValueErrors if datatypes do not match. If strict is False there will be the implicit conversion with possible loss of information.

[JuliaSprenger]

The strict option is a good idea, but I think it should be also available for section.merge and from there on be passed on to all merges of subsections and properties.

[jgrewe]

yes, agreed, would you mind to add it to issue #246, which was opened by Michi for the section append/extend/merge point you made

[JuliaSprenger]

Cool! I added a comment to the other issue. Then I think we can merge now.