Documentation for AmpAndLengthScale mentions internal attributes

[pmeier]

If amplitude and _length_scale should be public, we should remove the leading underscore. Otherwise they should be removed from the documentation.

[a-ws-m]

I think this is an interesting issue and I'm not sure what the best approach is. On the one hand, I don't think those attributes should be public; they should only be referenced within the class (or classes that inherit from AmpAndLengthScale, rather). On the other hand, I think it is useful to keep them in the documentation, as it relates to extending the API with one's own kernels, and they're necessary to interface with if you wish to do so. Any recommendations?
EDIT: My confusion might be based on a lack of intuition about what strictly ought to be "private".

[pmeier]

I've had quite a few discussion about this and I'm afraid there is no right answer here. My recommendation is the following: every public attribute or method of a class, i.e. no leading underscore, should have a proper use case for someone using that class. This also entails that the functionality is documented. Your case might be a little special due to the fact that we are talking about an ABC here.

I think it comes down to a matter of style, so I don't consider this a blocker. Feel free to close this with or without "fix".

[a-ws-m]

That makes sense, and thinking about this made me decide to redesign this part of the code. I think calling them amplitude and length_scale in the form that they were in is probably misleading because they weren't the actual amplitude and length scale used to parameterise the kernel; they were precursors that were passed through a different function, first. I've moved this functionality into amplitude and length_scale properties that are now documented.
I've decided to keep the newly renamed _amplitude_basis and _length_scale_basis attributes in the docs, however, as I think they're useful to know about for people who want to extend the API.