Fixed Parameter __setstate__ bug

[philippjfr]

This is a somewhat subtle bug and I have no minimal example except for trying to run through the panel Param notebook and trying to set Example.unbounded_float = 3.14.

• Fixes Setattr on parameters can fail when making a copy #265

[coveralls]

Coverage decreased (-0.2%) to 76.836% when pulling 9f3e0a4 on fix_parameter_copy into 56764fd on master.

[philippjfr]

Actually, here is a minimal example of the bug:

import param

class A(param.Parameterized):
    
    a = param.Number(default=0)
    
class B(A):
    
    pass

B.param.watch(lambda x: x, 'a', 'bounds')

B.a = 3.14

[ceball]

I can't do anything about this right now or review in detail, so excuse the brevity, but... (a) That method is just a hack to allow watching of parameter metadata (i.e. things other than value) - do we still need that? (If not, we could remove it and leave metadata watching as something to consider in the future.) (b) I imagine there are various times when watching should be suspended. Pickling, copying, initialization, etc. Respecting the 'initialized' flag or whatever it is is one of the to-do items, and will appear in the "depends cleanup" issue. (However, no doubt the __setattr__ method is bad anyway...) (c) I can't immediately think what the problem would be with your minimal example, i.e. how it would lead to the traceback you describe in the corresponding issue. I'd need to run it (or if you have a session where you already ran it, maybe you could copy/paste that...?)

…

On Tue, Sep 18, 2018 at 7:29 PM Philipp Rudiger ***@***.***> wrote: Actually, here is a minimal example: import param class A(param.Parameterized): a = param.Number(default=0) class B(A): pass B.param.watch(lambda x: x, 'a', 'bounds') B.a = 3.14 — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#266 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAHib5wwgSHU91GdLC3-LVx1fie4zXJks5ucTt2gaJpZM4Wue5u> .

[philippjfr]

That method is just a hack to allow watching of parameter metadata
(i.e. things other than value) - do we still need that?

Yes, I use it in panel and it works well.

I'd need to run it (or if you have a session where you
already ran it, maybe you could copy/paste that...?)

The example above leads directly to the traceback, it occurs when setting the parameter value on a subclass which did not define the parameter, because this triggers a copy operation on the parameter which in turn triggers __setstate__.

[ceball]

By the way, I'd be fine with this being merged and a new dev release being made so you can proceed with panel.

We can discuss more if necessary when reviewing the whole mechanism later on.