several issues in class Element

Bug #606361 reported by Sergio Miranda Freire on 2010-07-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Method __eq__ is not implemented correctly. It should return if two Element objects are equal according to some criterion and not whether an object is of type Element. The java implementers used equality of two elements based on the value attribute. I would prefer to use the attributes name and value.
It is advisable to use in the __hash__ method the same attributes used in __eq__. There are two hash(self.uid) in the method body. I'd rather remove both and use only name and value.

There are three invariants that are not enforced in the initializer:
Is_null_valid: is_null = (value = Void)
Null_flavour_indicated: is_null xor null_flavour = Void
Null_flavour_valid: is_null implies terminology(Terminology_id_openehr).has_code_for_group_id
(Group_id_null_flavour, null_flavour.defining_code)
     Here we will have to use the internal openehr terminology service.

In the initializer, why no call the initializer of the superclass ?

Related branches

Changed in oship:
importance: Undecided → High
milestone: none → 1.5
Tim Cook (timothywayne-cook) wrote :

If I understand correctly. There doesn't need to be an __eq__ implementation at all. The standard Python comparisons will correctly return a boolean indicating the result of a comparison. In the case of __eq__ it will only return True if two objects are the same object. This is the desired function; correct?


If you WANT to compare only attribute values and not the entire object identity. Then compare the __dict__ of the objects.

There is a good thread with examples at:

affects: oship → oshippy
Changed in oshippy:
milestone: 1.5 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers