oTree 5: None values in before_next_page

[ccr...@gmail.com]

Hi all -

I'm testing out otree 5 and converting a few existing otree 3 apps to the new format.  

I'm encountering a problem in a Page's before_next_page method.  I have a line of code where I assign the value of a player field to participant.vars:

player.participant.vars['current_q1_belief'] = player.q1_belief

When I submit that page, I get the following error for that line:

TypeError: player.q1_belief is None. Accessing a null field is considered an error.

This is an expected value for that field (and this app worked in oTree 3) - is this expected behavior?  Do I need to rewrite my software to avoid accessing fields who have value None?

Thanks,

--Chris

[Chris @ oTree]

Hi, you can do like this:

try:

  q1_belief = player.q1_belief

except TypeError:

  q1_belief = None

player.participant.vars['current_q1_belief'] = q1_belief

It's true that a field can be intentionally None, so it is not always an error. But now anyone who needs it intentionally can explicitly indicate so via the try/except. Forgetting to set a field is such a common error that I decided to add this null check. Because otherwise, it can cause incorrect behaviors that are hard for many people to trace. For example if someone had some code like "if player.q1_belief == True" etc.... it would just silently evaluate to False, etc. Even errors like "cannot add currency and NoneType" when someone does player.abc + player.xyz are common questions on the forum.

Let me know your thoughts,

Chris

[Chris @ oTree]

I wanted to add to that message like "You can override this by catching this exception", but that may just confuse people into thinking they need to catch the exception when they really need to find why the field in None in the first place...

[ccr...@gmail.com]

Hi Chris -

That makes sense - and it's just a slight shift in thought process when moving forward with the new version, certainly not anything which makes upgrading difficult or impossible.  I can see that the new restriction will hopefully help people track down their errors.

One other thing I have noticed is that in oTree<5, radio buttons had id="<fieldname>_N" and in oTree lite they have id="<fieldname>-N" (underscore_N to hyphen-N)- and when I had some javascript to update or disable those that that had to be updated manually.  I know that's not a huge thing, but I thought I'd mention it.

Thanks,

--Chris

[Chris @ oTree]

Thanks, I will take a look at the id=fieldname_N issue.

By the way, another way to prevent the error when accessing None is to set the field's initial value to something non-null, e.g.:

q1_belief = models.IntegerField(initial=0)