-
Notifications
You must be signed in to change notification settings - Fork 35
function method design
Michael Mommert edited this page Apr 23, 2019
·
4 revisions
Guidelines that have to be followed in the design of sbpy function and methods.
- astropy Quantities should always be preferred over other object types (e.g., simple floats)
-
Ephem
/Orbit
/Phys
objects should be used where appropriate; inheriting from either of these classes is strictly encouraged!
- by default, only the following data types are allowed for function input:
None
, dict orEphem
/Orbit
/Phys
, Quantity, float, int, string or iterable thereof - any dict provided should be turned into a
Ephem
/Orbit
/Phys
internally (functionality provided as part of sbpy.data.DataClass) - if only single properties of type Quantity, float, string (or iterables thereof) are provided that fit in either of
Ephem
/Orbit
/Phys
, this is permitted (for instance: a function/method takesphaseangle
as argument, but there are no other argument that would fit intoEphem
) - if there are two or more properties of type Quantity, float, string (or iterables thereof) that fit into either of
Ephem
/Orbit
/Phys
, those properties have to be bundled in the object (for instance: in addition tophaseangle
, a function/method also requires argumentheliodist
; both properties then have to be bundled into aEphem
object) - float, string, int (and iterables thereof) are only permitted as input parameters if their nature and unit is unambiguosly defined in the function/method docstring
- exceptions to the aforementioned guidelines can be granted to input parameters of private functions that depend on performance
- output properties should always be accompanied by a unit if applicable; permitted outputs are Quantity,
Ephem
/Orbit
/Phys
- any function/method that computes only a single property (e.g., Quantity, float, string, or iterable thereof) should output only this property as a Quantity
- if a function/method produces several output properties, these should be bundled in a
Ephem
/Orbit
/Phys
object; if the function/method takes aEphem
/Orbit
/Phys
as input and produces a result property that fits in to aEphem
/Orbit
/Phys
object, there should be a keyword argumentappend_results
that defines whether the resulting property gets added to the input object; by default,append_results=False
- other output data types (e.g., lists, floats, etc.) are only allowed in exceptional cases