embray / astropy Goto Github PK

For my own use, a todo list on astropy_helpers based on the last telecon discussion on the topic:

• Move Sphinx extensions from astropy to astropy_helpers
• Add --offline flag recognized by ah_bootstrap to force disabling of downloads
• When going to download from the internet, issue a warning message informing the user of the --offline option
• Add a custom sdist and extension to bdist commands to include astropy_helpers in distributions (it would not be included by default)
• In cases where astropy-helpers was bundled with a source distribution, add the option to automatically use a newer (compatible) version of astropy-helpers than the bundled one if available (this way bug fixes can be pushed out, etc.)
• Add setup.py test command to astropy_helpers, but with the provision that it requires astropy itself to be installed in order to fully function
• Per the APE draft, a _compiler module template should be provided.
• Discussion the rationale for the above points in the APE

A list of things I would like to update in the modeling package

• As mentioned in astropy#2235 parameter constraints should actually fix the allowed initial and update values for parameters
• Relatedly, all types of models should be allowed to have constraints on their parameters, even if they are not "fittable" models
• As a use case for that, some of the current "validation" done on some of the projection models' parameters would be implemented as constraints. For example on the cylindrical projections the relationship between lambda and mu could be implemented as a tied constraint rather than awkward use of setters.
• Remove getter/setter methods for parameters. I think it's too confusing that we would display parameters with one value, but use a different value for them internally. Currently this is used only for converting inputs in degrees to radians (for use in trig functions. But once we have proper support for Quantity this particular use case will go away, and so there will be no in practice use for getter/setter at all and they can just be removed.
• Consider including as part of model definitions details about what inputs and outputs a model receives, a la how parameters are specified. Currently we just specify an n_input and n_output, but some models really require more information on how different inputs and/or outputs should be formatted. It might also be helpful for documentation formatting and for passing information to fitters. For example some fitters currently hard-code a lot of special cases for polynomial models (see LinearLSQFitter._map_domain_window for example). Adding rules for input/output variables on the models themselves might help alleviate the need for special cases.