Better behavior for Integer defaults

[jbednar]

class P(param.Parameterized):
    val = param.Integer(4.0)

Should either coerce the provided value into an integer (which would be safe in this case, but may not be desirable if e.g. provided 4.3), or it should have a sensible error message. Instead it results in:

ValueError                                Traceback (most recent call last)
<ipython-input-32-f6658de6e3bd> in <module>()
----> 1 class P(param.Parameterized):
      2     val = param.Integer(4.0)
      3 
      4 

<ipython-input-32-f6658de6e3bd> in P()
      1 class P(param.Parameterized):
----> 2     val = param.Integer(4.0)
      3 
      4 

~/anaconda/envs/ds/lib/python3.6/site-packages/param/__init__.py in __init__(self, default, bounds, softbounds, inclusive_bounds, **params)
    588         self.inclusive_bounds = inclusive_bounds
    589         self._softbounds = softbounds
--> 590         if not callable(default): self._check_value(default)
    591 
    592 

~/anaconda/envs/ds/lib/python3.6/site-packages/param/__init__.py in _check_value(self, val)
    750 
    751         if not isinstance(val,int):
--> 752             raise ValueError("Parameter '%s' must be an integer."%self._attrib_name)
    753 
    754         self._checkBounds(val)

ValueError: Parameter 'None' must be an integer.

All things considered, I think that since we are explicitly declaring it to be an Integer, we should try converting whatever we are given into an integer. In any case, we need to fix the broken attrib name here.

[ceball]

I think that since we are explicitly declaring it to be an Integer, we should try converting whatever we are given into an integer

To me, that feels like making things more complex (in implementation and behavior) for a benefit I can't quite see.

Also, where would you draw the line? You mention 4.3 as not being acceptable, but what about e.g. "4"?

In any case, we need to fix the broken attrib name here.

If you were to just type in val = param.Integer(4.0) at a prompt, would you expect param.Integer to know about the name val?

I'm not saying what you're asking for is impossible, just that it's not an accidental oversight...

[jbednar]

The above example wasn't how this actually came up in practice. I looked into it further, and found that it wasn't actually a float value that led to this message, it was a numpy.int64 value extracted from a Pandas dataframe (the min and max of a column that was originally ints). Same message, but that seems pretty clear: it's a numeric type, but not a Python int, and so I expected to work as a param.Integer. Seem any more reasonable to convert that?

Anyway, how could "None" not be the result of an accidental oversight? If the name isn't known, then the message shouldn't be trying to print the name.

[ceball]

Seem any more reasonable to convert that?

Just to be clear: I guess you're proposing to accept a variety of integer types (i.e. not only python int), rather than to convert? I definitely agree it should be fine to use e.g. a numpy integer as the value of a param.Integer (whereas converting seems confusing and risky to me), and it's bad that we've apparently been rejecting those types all this time.

For accepting a variety of integer types, would it be enough to have a list of integer types, defaulting to [int], with e.g. numpy.integer added if numpy present? Then changing the isinstance test to be over the list? Or is there a better way? (Is a list of specific types too restrictive?)

Anyway, how could "None" not be the result of an accidental oversight? If the name isn't known, then the message shouldn't be trying to print the name.

Ah, right, this is true and I agree we should fix it. (I thought you were referring to the fact the name is unknown.)

[jbednar]

Ah, I think you're right: accept, not convert. Good point. There's a discussion of checking for numpy/python ints on SO.

[tonyfast]

This is a breaking change. Let us see if this is needed in 2.0.