InExcludeData\BaseList2d link confusion

Helper

On 26/01/2013 at 09:07, xxxxxxxx wrote:

Hi,

i have got a BaseTag for which i have to throttle the tag execution for performance
reasons. i am using a custom isdirty method, with which i am comparing the currrent
state of the tag and its linked objects with a cached state. to do this, i also cache the
basecontainer of the tag to compare this cache with copies of the tag basecontainer
created at a later point.
my tag contains LinkBoxGui and a InExcludeCustomGui elements. when i compare
these containers against each other the result is always False, unless i clear out
the link values before i store my bc cache.

is this intended ? shouldn't __eq__ compare the objects cotained in the link fields in
a boolean manner (or ignore them) rather than checking if they are actually the same
object with the same memory address ? are my assumptions correct or am i doing
something wrong here ?

class foo(object) :
	def __init__(self) :
		self.Cache = None
  
	def methodA(self, node) :
		self.Cache = node.GetData()
  
	def methodB(self, node) :
		# always true
		if self.Cache != node.GetData() :
			pass

a link to the complete isDirty() method.

Helper

On 31/01/2013 at 22:58, xxxxxxxx wrote:

Hi Ferdinand,

imo it makes more sense when comparing link-fields, if the objects are actually
the same, and not just have the same properties. I'm not even sure if
the InExcludeData actually implements a specialized __eq__ behavior.

my tip: compare them yourself the way you want.

Best,
Niklas

Helper

On 05/02/2013 at 16:28, xxxxxxxx wrote:

InExcludeData does not, but BaseContainer does. But BaseContainer also has a DirtyCount
method which I totally overlook at that point and which is working as expected for me.
However i still think this could be considered as a bug. BaseContainer should skip values which
are not comparable in a boolean manner (not providing the rich comparison methods). Currently
there is no difference between == and is for BaseContainers containing any object links. You
can hardly call this intended or expected behaviour imho.