This seems fine; though now that parameter initial values are passed all the way to the Model base class, I wonder if it shouldn't also handle setting those initial values a la ParametricModel._initialize_parameters. That would allow eliminating slight oddities like those in in the projection models where you have, for example,

def __init__(self, mu=0.0, gamma=0.0):
    super(Sky2Pix_AZP, self).__init__(mu=mu, gamma=gamma)
    self.mu = mu
    self.gamma = gamma

Now that initial parameter values are checked by the base class, the repetition of this kind of boilerplate suggests that setting the parameters should be handled in Model.__init__ as well. The only difference between Model._initialize_parameters and ParametricModel._initialize_parameters is that the latter would also initialize the ._parameters array.

Though building further on that point, I wonder if then all models could have a ._parameters array. This would, I think, simplify the implementation of Parameter a bit and reduce the difference between ParametricModel and any other type of model. I think the only thing that should really distinguish ParametricModel is its support for fit constraints.

I am increasingly uncomfortable with the fact that depending on the base class models treat parameters in a different way. This makes the code hard to maintain and hard to understand because one needs to understand both ways. To illustrate what I mean:

for a ParametricModel

In [13]: g1=models.Gaussian1D(1,2,3)

In [14]: g1.__dict__
Out[14]: 
{'_constraints': {},
 '_eqcons': [],
 '_ineqcons': [],
 '_param_dim': 1,
 '_param_metrics': {u'amplitude': (slice(0, 1, None), ()),
  u'mean': (slice(1, 2, None), ()),
  u'stddev': (slice(2, 3, None), ())},
 '_param_total_size': 3,
 '_parameters': array([ 1.,  2.,  3.])}

for a model which subclasses directly Model

azp=models.Pix2Sky_AZP(1,2)

In [18]: azp.__dict__
Out[18]: 
{'_gamma': 0.034906585039886591,
 '_mu': 1.0,
 '_param_dim': 1,
 '_param_metrics': {u'gamma': (slice(1, 2, None), ()),
  u'mu': (slice(0, 1, None), ())},
 '_param_total_size': 2}

Non-fittable models own their parameters, while fittable models own ._parameters.

Treating parameters in a uniform way would be much preferable but I don't think we should make all models have ._parameters and behave like fittable models do now.

Another reason why implementing Parameter as a descriptor and defining model parameters as class variables is not good is that in this way Parameter can have only attributes which are the same for all instances. This makes it harder to have Parameter.value or Parameter.unit or any other attribute unless it applies to all instances. Essentially these have to be set on the model as is now done with value.

I think a better way would be to have a regular Parameter object which holds its value and any other attributes specified when the class is initialized. And have a ParameterDescriptor to access them.

The first part--"depending on the base class models treat parameters in a different way"--I agree with. The second part I'm not so sure. I don't know what you mean by a "ParameterDescriptor". Parameter is already a descriptor and I don't see the point in throwing on more classes. Maybe one thing that would improve flexibility and simply the code is provide an internally used interface whereby individual model types can inform parameter instances bound to a model how to access the actual parameter values stored on the model. IIRC I already did that by having Parameter instances using getattr on the model they are bound to, but I don't remember exactly. I'd have to check the code. But I still feel like making the Parameter instances themselves store the value is asking for trouble. I still see the Parameter interface as merely an API convenience, and not something that should be intrinsic to the data models that individual Model types use to store their parameters.

In other words, I feel like a Model should be responsible for handling its own data. Not some other extra class.

@embray I was suggesting renaming the current Parameter class to ParameterDescriptor (or something else) and having a regular Parameter class which stores the value and other information if needed. This new parameter class can subclass Quantity. Why is it a bad idea to store the value of a parameter in Parameter instances owned by the model? I see it as equivalent to storing quantities with the option of adding more attributes if needed.

If we were to make Parameter a special subclass of Quantity (I'm not really sure how I feel about that--Parameter really serves a different purpose as being purely information about a model--how, for example, is a constraint relevant to a stand-alone "Parameter" instance except in the context of fitting a model?)

But even if we did that one part of the design of the Parameter class is that it can be used as a descriptor or as a concrete object. That way when defining a model, the author doesn't have to write:

class MyModel(Model):
    a = ParameterDescriptor(...)
    b = ParameterDescriptor(...)

they only have to remember one interface:

class MyModel(Model):
    a = Parameter(...)
    b = Parameter(...)

I don't think it makes the interface that much more complicated, because the __new__ for Parameter (or maybe it's the __init__--I forget) quickly determines whether this is a "concrete" parameter instance or descriptor for a parameter.