Re: Reaction ( trellis-fork )

[Edwin]

Hi Sergey Schetinin,

Thank you for your previous answer. This time I have CC-ed the mailing list as you have asked me. ( Again, I am not a Python expert so forgive me if some details are not exactly correct ).

BTW, what those packages were? All required packages should install
automatically, unless there's something missing in
setup(install_requires=...)

The packages were Setuptools (maybe trivial...) and Noose.

I'm not sure why Jython reports a conflict, as __slots__ are supposed
to work with inheritance -- there's no actual conflict in there, at
least with CPython semantics. The easy solution would be to ditch
slots on Jython completely -- that would probably make the conflict go
away, but the reason for using __slots__ is that it reduces memory
usage (by about 10x for Reaction cells in my tests). I can't seem to
find a definitive answer on how __slots__ are implemented in Jython
and if there's any win in using them.

Anyway, just to confirm, try commenting out the "__slots__ = ..."
lines for those baseclasses and see if tests pass. If that works out,
we could add that fix to the trunk (it would still use slots on
CPython).

The error that Jython spit out was with the original package:

    class ComputeRule(RuleBase, AutoDisconnectMixin):

TypeError: Error when calling the metaclass bases

    multiple bases have instance lay-out conflict

I have tried the following patch and then this error is gone:

Index: compute.py

===================================================================

--- compute.py (revision 257)

+++ compute.py (working copy)

@@ -17,7 +17,7 @@

         cell.disconnect()

 

 class AutoDisconnectMixin(HasListenersBase):

-    __slots__ = ()

+    #__slots__ = ()

     def __init__(self):

         super(AutoDisconnectMixin, self).__init__()

         Connector(self, disconnector)

So apparently the slots statement is the culprit and after some googling it seems that a conflicting slots statement in two base classes in the case of multiple inheritance can cause this. I do not know why it is a problem in Jython but not in CPython. Can you explain this behaviour ?

The next step I tried was to try and run the first of the unittests ( STM_Observer ). The tests were not all succesfull, for example:

line 298, in STM-Observer.txt

Failed example:

    list(s1.iter_listeners())==list(s2.iter_listeners())==[l2]

Expected:

    True

Got:

    False

The reason for this IMO is that Jython depends on the Java garbage collector and CPython on reference counting and that in the case of weak referencing there is a difference in behaviour. ( In Jython there are still two links l1,l2 instead of only one ). Apparently the tests are sensitive for the type of garbage collection ? IMO there are two possibilities: either the test is too restrictive and should not depend on this or the test is correct and the package itself also depends on the behaviour of the garbage collector. If that is the case isn't it a bug, since as far as I can tell the language spec does not enforce either behaviour ?

The next UnitTest ( Internals ) also revealed some subtle differences, for example:

line 41, in Internals.txt

Failed example:

    IsOptional(Test)

Expected:

    {'y': True, 'x': True}

Got:

    {'x': True, 'y': True}

 The reason for this is that apparently according to the Python language specification the order of Dict elements can be arbitrary per implementation but should be stable / deterministic. Apparently the ordering of Jython and CPython is different for a Dict ( and this is acceptable according to the language spec ).

The following test is successful by the way: IsOptional(Test)=={'y': True, 'x': True}

Again I don't have enough knowledge, but either the test is too restrictive and should not be sensitive for the Dict ordering or the Test is correct and the package is also sensitive on Dict ordering, but that would be a bug then because the language specification does not enforce this behaviour ?

Thanks in advance for your help!

Best regards,

Edwin

 

[Sergey Schetinin]

2009/8/19 Edwin <edwind...@gmail.com>:

There can be a conflict if bases define the same slots, but this is
not the case here, so it's some Jython-specific limitation, probably
Jython __slots__ implementation doesn't play nice with "diamond"
inheritance. I'll add a workaround so that specific __slots__
definition will be skipped on Jython.

> The next step I tried was to try and run the first of the unittests (
> STM_Observer ). The tests were not all succesfull, for example:
> line 298, in STM-Observer.txt
> Failed example:
>     list(s1.iter_listeners())==list(s2.iter_listeners())==[l2]
> Expected:
>     True
> Got:
>     False
> The reason for this IMO is that Jython depends on the Java garbage collector
> and CPython on reference counting and that in the case of weak referencing
> there is a difference in behaviour. ( In Jython there are still two links
> l1,l2 instead of only one ).

Do I understand correctly that if someone running Jython does

>>> o = object()
>>> del o

That doesn't necessarily mean that that object is destroyed at that point?

> Apparently the tests are sensitive for the type
> of garbage collection ? IMO there are two possibilities: either the test is
> too restrictive and should not depend on this or the test is correct and the
> package itself also depends on the behaviour of the garbage collector. If
> that is the case isn't it a bug, since as far as I can tell the language
> spec does not enforce either behaviour ?

That behavior is not critical to functionality of the library, so I
guess that test should be made conditional on platform. Please confirm
that I understand the GC behavior correctly and I'll change that test.

> The next UnitTest ( Internals ) also revealed some subtle differences, for
> example:
> line 41, in Internals.txt
> Failed example:
>     IsOptional(Test)
> Expected:
>     {'y': True, 'x': True}
> Got:
>     {'x': True, 'y': True}
>
>  The reason for this is that apparently according to the Python language
> specification the order of Dict elements can be arbitrary per implementation
> but should be stable / deterministic. Apparently the ordering of Jython and
> CPython is different for a Dict ( and this is acceptable according to the
> language spec ).
> The following test is successful by the way: IsOptional(Test)=={'y': True,
> 'x': True}
> Again I don't have enough knowledge, but either the test is too restrictive
> and should not be sensitive for the Dict ordering or the Test is correct and
> the package is also sensitive on Dict ordering, but that would be a bug then
> because the language specification does not enforce this behaviour ?

I fixed that in the trunk.

> Thanks in advance for your help!
> Best regards,
> Edwin
>

--
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter