Should the values paramater be value in slicing.py?

[genedan]

While working on annotations in slicing.py, I came across a method for setting values on a sparse backend that seems to be written to replace data at a single coordinate with a scalar:

chainladder-python/chainladder/core/slice.py

Lines 151 to 168 in 11f6263

	def _sparse_setitem(self, key, values):
	check = (
	(self.obj.values.coords[0] == key[0]) *
	(self.obj.values.coords[1] == key[1]) *
	(self.obj.values.coords[2] == key[2]) *
	(self.obj.values.coords[3] == key[3]))
	if check.max():
	data_index = np.where(check == True)[0][0]
	self.obj.values.data[data_index] = values
	else:
	self.obj.values.coords = np.concatenate(
	(self.obj.values.coords, np.array(key)[:, None]), 1)
	self.obj.values.data = np.concatenate(
	(self.obj.values.data, np.array([values])), 0)
	self.obj.values = self.obj.get_array_module().COO(
	self.obj.values.coords, self.obj.values.data, prune=True,
	has_duplicates=False, shape=self.obj.shape,
	fill_value=self.obj.values.fill_value)

In this case, value would make more grammatical sense. But I looked further and there's some evidence that in general value might align more closely with the Python data model and what the Pydata libraries do. For example, in this file, which contains the source code for DataFrame indexing:

https://github.com/pandas-dev/pandas/blob/72f2fea91530b5abb3cf2100cb22d84e504695c0/pandas/core/indexing.py#L2577-L2593

Also the various instances of __setitem__ in that file use the keyword argument value, compared to chainladder which uses values for the corresponding functions. But the Pandas library is huge, so I have yet to know whether this is consistent, or applies to cases with more than one data point, like setting ndarrays. Since this is kind of a sidequest that arose out of typing work, I left it as a question here, but if confirmed, we should get the change done before 1.0 since it's an API change.

[kennethshsu]

There are lots of places in the package that does this, for example, DevelopmentConstant() currently uses patterns, even though only 1 pattern is accepted.

And not directly related, there are also other parameter names that are not great.

For example .ibnr_ from the IBNR models, is not always IBNR (would be unpaid from paid data), I think .unemerged_ would be a better choice. Or the Triangle() class uses development, but it's really valuation, because development are more like ages (e.g. 12, 24, etc), but it takes valuation in dates (e.g. 2004-12-31).