The Astronomical Journal, 156:123 (19pp), 2018 September https://doi.org/10.

3847/1538-3881/aabc4f
© 2018. The American Astronomical Society.

The Astropy Project: Building an Open-science Project and Status of the v2.0 Core
Package*
The Astropy Collaboration, A. M. Price-Whelan1 , B. M. Sipőcz44, H. M. Günther2, P. L. Lim3, S. M. Crawford4 , S. Conseil5,
D. L. Shupe6, M. W. Craig7, N. Dencheva3, A. Ginsburg8 , J. T. VanderPlas9 , L. D. Bradley3 , D. Pérez-Suárez10,
M. de Val-Borro11
(Primary Paper Contributors),
T. L. Aldcroft12, K. L. Cruz13,14,15,16 , T. P. Robitaille17 , E. J. Tollerud3
(Astropy Coordination Committee),
and
C. Ardelean18, T. Babej19, Y. P. Bach20, M. Bachetti21 , A. V. Bakanov98, S. P. Bamford22, G. Barentsen23, P. Barmby18 ,
A. Baumbach24, K. L. Berry98, F. Biscani25, M. Boquien26, K. A. Bostroem27, L. G. Bouma1, G. B. Brammer3 , E. M. Bray98,
H. Breytenbach4,28, H. Buddelmeijer29, D. J. Burke12, G. Calderone30, J. L. Cano Rodríguez98, M. Cara3, J. V. M. Cardoso23,31,32,
S. Cheedella33, Y. Copin34,35, L. Corrales36,99, D. Crichton37, D. D’Avella3, C. Deil38, É. Depagne4, J. P. Dietrich39,40, A. Donath38,
M. Droettboom3, N. Earl3, T. Erben41, S. Fabbro42, L. A. Ferreira43, T. Finethy98, R. T. Fox98, L. H. Garrison12 ,
S. L. J. Gibbons44, D. A. Goldstein45,46, R. Gommers47, J. P. Greco1, P. Greenfield3, A. M. Groener48, F. Grollier98, A. Hagen49,50,
P. Hirst51, D. Homeier52 , A. J. Horton53, G. Hosseinzadeh54,55 , L. Hu56, J. S. Hunkeler3, Ž. Ivezić57, A. Jain58, T. Jenness59 ,
G. Kanarek3, S. Kendrew60 , N. S. Kern45 , W. E. Kerzendorf61, A. Khvalko98, J. King38, D. Kirkby62, A. M. Kulkarni63,
A. Kumar64, A. Lee65, D. Lenz66, S. P. Littlefair67, Z. Ma68, D. M. Macleod69, M. Mastropietro70, C. McCully54,55 ,
S. Montagnac71, B. M. Morris57 , M. Mueller72, S. J. Mumford73, D. Muna74, N. A. Murphy12, S. Nelson7, G. H. Nguyen75,
J. P. Ninan50, M. Nöthe76, S. Ogaz3, S. Oh1, J. K. Parejko57, N. Parley77, S. Pascual78 , R. Patil98, A. A. Patil79,
A. L. Plunkett80 , J. X. Prochaska81 , T. Rastogi98, V. Reddy Janga82, J. Sabater83, P. Sakurikar84, M. Seifert98, L. E. Sherbert3,
H. Sherwood-Taylor98, A. Y. Shih85, J. Sick86, M. T. Silbiger98, S. Singanamalla87, L. P. Singer88,89 , P. H. Sladen90,
K. A. Sooley98, S. Sornarajah98, O. Streicher91, P. Teuben92 , S. W. Thomas44, G. R. Tremblay12 , J. E. H. Turner93, V. Terrón94,
M. H. van Kerkwijk95, A. de la Vega37 , L. L. Watkins3 , B. A. Weaver96, J. B. Whitmore97, J. Woillez61 , and V. Zabalza98
(Astropy Contributors)
1
Department of Astrophysical Sciences, Princeton University, Princeton, NJ 08544, USA; coordinators@astropy.org
2
Kavli Institute for Astrophysics and Space Research, Massachusetts Institute of Technology, 70 Vassar St., Cambridge, MA 02139, USA
3
Space Telescope Science Institute, 3700 San Martin Dr., Baltimore, MD 21218, USA
4
South African Astronomical Observatory, P.O. Box 9, Observatory 7935, Cape Town, South Africa
5
Univ Lyon, Univ Lyon1, Ens de Lyon, CNRS, Centre de Recherche Astrophysique de Lyon UMR5574, F-69230, Saint-Genis-Laval, France
6
Caltech/IPAC, 1200 E. California Blvd, Pasadena, CA 91125, USA
7
Department of Physics and Astronomy, Minnesota State University Moorhead, 1104 7th Ave S, Moorhead, MN 56563, USA
8
National Radio Astronomy Observatory, 1003 Lopezville Rd, Socorro, NM 87801, USA
9
eScience Institute, University of Washington, 3910 15th Ave NE, Seattle, WA 98195, USA
10
University College London/Research IT Services, Gower St, Bloomsbury, London WC1E 6BT, UK
11
Astrochemistry Laboratory, NASA Goddard Space Flight Center, 8800 Greenbelt Road, Greenbelt, MD 20771, USA
12
Harvard-Smithsonian Center for Astrophysics, 60 Garden St., Cambridge, MA, 02138, USA
13
Department of Physics and Astronomy, Hunter College, City University of New York, 695 Park Avenue, New York, NY 10065, USA
14
Physics, Graduate Center of the City University of New York, New York, NY, USA
15
Department of Astrophysics, American Museum of Natural History, New York, NY, USA
16
Center for Computational Astropyhsics, Flatiron Institute, 162 Fifth Avenue, New York, NY 10010, USA
17
Aperio Software Ltd., Headingley Enterprise and Arts Centre, Bennett Road, Leeds, LS6 3HN, UK
18
Department of Physics & Astronomy, University of Western Ontario, 1151 Richmond St, London ON N5X4H1 Canada
19
Department of Theoretical Physics & Astrophysics, Masaryk University, Kotlarska 2, 61137 Brno, Czech Republic
20
Department of Physics and Astronomy, Seoul National University, Gwanak-gu, Seoul 08826, Republic of Korea
21
INAF-Osservatorio Astronomico di Cagliari, via della Scienza 5, I-09047, Selargius, Italy
22
School of Physics & Astronomy, University of Nottingham, University Park, Nottingham NG7 2RD, UK
23
NASA Ames Research Center, Moffett Field, CA 94043, USA
24
Heidelberg University, Kirchhoff Institut for Physics, Im Neuenheimer Feld 227, D-69116 Heidelberg, Germany
25
Max-Planck-Institut für Astronomie, Königstuhl 17, D-69117 Heidelberg, Germany
26
Unidad de Astronomía Fac. Cs. Básicas, Universidad de Antofagasta, Avda.U. de Antofagasta 02800, Antofagasta, Chile
27
Department of Physics, UC Davis, 1 Shields Ave, Davis, CA, 95616, USA
28
Department of Astronomy, University of Cape Town, Private Bag X3, Rondebosch 7701, South Africa
29
Leiden Observatory, Leiden University, P.O. Box 9513, 2300 RA, Leiden, The Netherlands
30
Istituto Nazionale di Astrofisica, via Tiepolo 11 Trieste, Italy
31
Universidade Federal de Campina Grande, Campina Grande, PB 58429-900, Brazil
32
Bay Area Environmental Research Institute, Petaluma, CA 94952, USA
33
Department of Physics, Virginia Tech, Blacksburg, VA 24061, USA
34
Université de Lyon, F-69622, Lyon, France

*
The author list has three parts: the authors that made significant contributions to the writing of the paper in order of contribution, the four members of the Astropy
Project coordination committee, and contributors to the Astropy Project in alphabetical order. Their position in the author list does not correspond to contributions to
the Astropy Project as a whole. A more complete list of contributors to the core package can be found in thepackage repository and at theAstropy team webpage.

1
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.
35
Université de Lyon 1, Villeurbanne; CNRS/IN2P3, Institut de Physique Nucléaire de Lyon, France
36
University of Wisconsin—Madison, 475 North Charter Street, Madison, WI 53706, USA
37
Department of Physics and Astronomy, Johns Hopkins University, Baltimore, MD 21218, USA
38
Max-Planck-Institut für Kernphysik, P.O. Box 103980, D-69029 Heidelberg, Germany
39
Faculty of Physics, Ludwig-Maximilians-Universität, Scheinerstr. 1, D-81679 Munich, Germany
40
Excellence Cluster Universe, Boltzmannstr. 2, D-85748 Garching b. München, Germany
41
Argelander-Institut für Astronomie, Auf dem Hügel 71, D-53121 Bonn, Germany
42
National Research Council Herzberg Astronomy & Astrophysics, 4071 West Saanich Road, Victoria, BC, Canada
43
Instituto de Matemática Estatística e Física—IMEF, Universidade Federal do Rio Grande—FURG, Rio Grande, RS 96203-900, Brazil
44
Institute of Astronomy, University of Cambridge, Madingley Road, Cambridge, CB3 0HA, UK
45
Department of Astronomy, UC Berkeley, 501 Campbell Hall #3411, Berkeley, CA 94720, USA
46
Lawrence Berkeley National Laboratory, 1 Cyclotron Road, Berkeley, CA 94720, USA
47
Scion, Private Bag 3020, Rotorua, New Zealand
48
Drexel University, Physics Department, Philadelphia, PA 19104, USA
49
Vizual.ai, 3600 O’Donnell St, Suite 250, Baltimore, MD 21224, USA
50
Dept of Astronomy and Astrophysics, Pennsylvania State University, University Park, PA 16802, USA
51
Gemini Observatory, 670 N. Aohoku Pl, Hilo, HI 96720, USA
52
Zentrum für Astronomie der Universität Heidelberg, Landessternwarte, Königstuhl 12, D-69117 Heidelberg, Germany
53
Australian Astronomical Observatory, 105 Delhi Road, North Ryde NSW 2113, Australia
54
Las Cumbres Observatory, 6740 Cortona Drive, Suite 102, Goleta, CA 93117-5575, USA
55
Department of Physics, University of California, Santa Barbara, CA 93106-9530, USA
56
Imperial College London, Kensington, London SW7 2AZ, UK
57
Department of Astronomy, University of Washington, Seattle, WA 98155, USA
58
BITS PILANI/Computer Science, Pilani Campus, Rajasthan, India
59
Large Synoptic Survey Telescope, 950 N. Cherry Ave., Tucson, AZ, 85719, USA
60
European Space Agency, Space Telescope Science Institute, 3700 San Martin Dr., Baltimore, MD 21218, USA
61
European Southern Observatory, Karl-Schwarzschild-Straße 2, D-85748 Garching bei München, Germany
62
Department of Physics and Astronomy, University of California, Irvine, CA 92697, USA
63
College of Engineering Pune/Department of Computer Engineering and IT, Shivajinagar, Pune 411005, India
64
Delhi Technological University, India
65
Department of Physics, University of Berkeley, California, CA94709, USA
66
Jet Propulsion Laboratory, California Institute of Technology, 4800 Oak Grove Drive, Pasadena, CA 91109, USA
67
Department of Physics & Astronomy, University of Sheffield, Sheffield, S3 7RH, UK
68
Department of Physics and Astronomy, University of Missouri, Columbia, Missouri, 65211, USA
69
Cardiff University, Cardiff CF24 3AA, UK
70
Department of Physics and Astronomy, Ghent University, Krijgslaan 281, S9, B-9000 Gent, Belgium
71
Puy-Sainte-Réparade Observatory, France
72
Department of Mathematics, Brown University, 151 Thayer Street, Providence, RI 02912, USA
73
SP 2RC , School of Mathematics and Statistics, The University of Sheffield, UK
74
Center for Cosmology and Astroparticle Physics, The Ohio State University, 191 West Woodruff Avenue, Columbus, OH 43210, USA
75
VNU-HCMC, University of Natural Sciences/Faculty of IT, 227 Nguyen Van Cu St., Ward 4, District 5, Ho Chi Minh City, Vietnam
76
Experimental Physics 5, TU Dortmund, Otto-Hahn-Str. 4, D-44227 Dortmund, Germany
77
University of Reading, Whiteknights Campus, Reading RG6 6BX, UK
78
Departamento de Astrofisica, Universidad Complutense de Madrid, Madrid, Spain
79
Pune Institute of Computer Technology, Pune 411043, India
80
European Southern Observatory, Av. Alonso de Córdova 3107, Vitacura, Santiago, Chile
81
Astronomy & Astrophysics, UC Santa Cruz, 1156 High St., Santa Cruz, CA 95064 USA
82
Indian Institute of Technology, Mechanical Engineering, Kharagpur, India
83
Institute for Astronomy (IfA), University of Edinburgh, Royal Observatory, Blackford Hill, EH9 3HJ Edinburgh, UK
84
IIIT-Hyderabad, India
85
NASA Goddard Space Flight Center, 8800 Greenbelt Road, Greenbelt, MD 20771, USA
86
AURA/LSST, 950 N Cherry Ave, Tucson, 85719, USA
87
Microsoft Research, Redmond, WA 98053, USA
88
Astroparticle Physics Laboratory, NASA Goddard Space Flight Center, 8800 Greenbelt Road, Greenbelt, MD 20771, USA
89
Joint Space-Science Institute, University of Maryland, College Park, MD 20742, USA
90
Zentrum für Astronomie der Universität Heidelberg, Astronomisches Rechen-Institut, Mönchhofstraße 12-14, D-69120 Heidelberg, Germany
91
Leibniz Institute for Astrophysics Potsdam (AIP), An der Sternwarte 16, D-14482 Potsdam, Germany
92
Astronomy Department, University of Maryland, College Park, MD 20742, USA
93
Gemini Observatory, Casilla 603, La Serena, Chile
94
Institute of Astrophysics of Andalusia (IAA-CSIC), Granada, Spain
95
Department of Astronomy & Astrophysics, University of Toronto, 50 Saint George Street, Toronto, ON M5S 3H4, Canada
96
National Optical Astronomy Observatory, 950 N. Cherry Ave., Tucson, AZ 85719, USA
97
Centre for Astrophysics and Supercomputing, Swinburne University of Technology, Hawthorn, VIC 3122, Australia
Received 2018 January 8; revised 2018 March 27; accepted 2018 March 29; published 2018 August 24

98

99
The Astropy Project.
Einstein Fellow.

Original content from this work may be used under the terms
of the Creative Commons Attribution 3.0 licence. Any further
distribution of this work must maintain attribution to the author(s) and the title
of the work, journal citation and DOI.

2
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Abstract
The Astropy Project supports and fosters the development of open-source and openly developed Python
packages that provide commonly needed functionality to the astronomical community. A key element of the
Astropy Project is the core package astropy, which serves as the foundation for more specialized projects and
packages. In this article, we provide an overview of the organization of the Astropy project and summarize key
features in the core package, as of the recent major release, version 2.0. We then describe the project infrastructure
designed to facilitate and support development for a broader ecosystem of interoperable packages. We conclude
with a future outlook of planned new features and directions for the broader Astropy Project.
Key words: methods: data analysis – methods: miscellaneous – methods: statistical – reference systems

1. Introduction arithmetic (numpy; Van der Walt et al. 2011), a wide variety of
functions for scientific computing (scipy; Jones et al. 2001),
All modern astronomical research makes use of software in
and publication-quality plotting (matplotlib; Hunter 2007),
some way. Astronomy, as a field, has thus long supported the
tens of thousands of other high-quality and easy-to-use packages
development of software tools for astronomical tasks, such as
are available to help with tasks that are not specific to astronomy
scripts that enable individual scientific research, software
but might be performed in the course of astronomical research,
packages for small collaborations, and data reduction pipelines
e.g., interfacing with databases, or statistical inferences. More
for survey operations. Some software packages are, or were,
recently, the development and mainstream adoption of package
supported by large institutions and intended for a wide range of managers such as Anaconda101 has significantly streamlined the
users. These packages therefore typically provide some level of installation process for many libraries, lowering the barriers to
documentation and user support or training. Other packages are entry for new users.
developed by individual researchers or research groups, are The Astropy Project aims to provide an open-source and
then typically used by smaller groups for more domain-specific open-development core package (astropy) and an ecosystem
purposes, and may have less extensive user support. For both of affiliated packages that support astronomical functionality in
packages meant for wider distribution and for scripts specific to the Python programming language. “Open development”
particular research projects, a library that addresses common describes a process where anybody with an internet connection
astronomical tasks simplifies the software development process can suggest changes to the source code and contribute their
by encouraging the reuse of common functions. The users of opinion when new features, bug fixes or other code changes,
such a library then also benefit from a community and governance, or any other aspect of the development process is
ecosystem built around a shared foundation. The Astropy discussed (see Sections 2.2 and 2.3 of how this is organized in
project has grown to become such a community for Python practice). The astropy core package is now a feature-rich
astronomy software, and the astropy core package has library of sufficiently general tools and classes that supports the
become this shared foundation. development of more specialized code. An example of such
The development of the astropy core package began as a functionality is reading and writing FITS files: it would be
largely community-driven effort to standardize core function- time-consuming and impractical for multiple groups to
ality for astronomical software in Python. In this way, its implement the FITS standard (Pence et al. 2010) and maintain
genesis differs from, but builds upon, many substantial and software for such a general-purpose need. Another example of
former astronomical software development efforts that were such a common task is in dealing with representations of and
commissioned or initiated through large institutional support, transformations between astronomical coordinate systems.
such as IRAF (developed at NOAO; Tody 1993), MIDAS The Astropy Project aims to develop and provide high-
(developed at ESO; Banse et al. 1988), or Starlink (originally quality code and documentation according to the best practices
developed by a consortium of UK institutions and now in software development. The project makes use of different
maintained by the East Asian Observatory; Disney & Wallace tools and web services to reach those goals without central
1982; Currie et al. 2014). More recently, community-driven institutional oversight. The first public release of the astropy
efforts have seen significant success in the astronomical package is described in Astropy Collaboration et al. (2013).
sciences (e.g., Turk et al. 2011). Since then, the astropy package has been used in hundreds
Python100 is an increasingly popular, general-purpose of projects and the scope of the package has grown
programming language that is available under a permissive considerably. At the same time, the scientific community
open-source software license and is free of charge for all major contributing to the project has grown tremendously and an
operating systems. This programming language has become ecosystem of packages supporting or affiliated with the
especially popular in the quantitative sciences, where researchers astropy core has developed. In this paper, we describe the
must simultaneously conduct research, perform data analysis, current status of the Astropy community and the astropy
and develop software. A large part of this success owes itself to core package and discuss goals for future development.
the vibrant community of developers and a continuously We start by describing the way the Astropy Project functions
growing ecosystem of tools, web services, and stable, well- and is organized in Section 2. We then describe the main
developed packages that enable easier collaboration on software software efforts developed by the Astropy Project itself: a core
development, easier writing and sharing of software documenta- package called astropy (Section 3) and several separate
tion, and continuous testing and validation of software. While packages that help maintain the infrastructure for testing and
dedicated libraries provide support for array representation and documentation (Section 4). We end with a short vision for the
100 101
https://www.python.org/ https://anaconda.org/

3
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 1. Left panel: distribution of number of commits per committer. Middle panel: cumulative number of commits to the astropy core package over time. Right
panel: number of unique committers per month to the astropy core package.

future of Astropy and astronomical software in general in implement new features, or improve or modify the infrastructure
Section 5. The full paper, including the code to produce the that supports the development and maintenance of the package.
figures, is available in a GitHub repository (Price-Whelan Individual pull requests are generally limited to a single
et al. 2018).102 conceptual addition or modification, to make code review
This article is not intended as an introduction to astropy, tractable. Pull requests that modify or add code to a specific
nor does it replace the astropy documentation. Instead, it subpackage must be reviewed and approved by one of the
describes the way the Astropy community is organized and the subpackage maintainers before they are merged into the core
current state of the astropy package. codebase. Bugs and feature requests are reported via the
GitHub issue tracker and labeled with a set of possible labels
2. Organization and Infrastructure that help classify and organize the issues. The development
workflow is detailed in the astropy documentation.105
2.1. Coordination of Astropy As of version 2.0, astropy contains 212,244 lines of
From its inception, Astropy has required coordination to code106 contributed by 232 unique contributors over 19,270 git
ensure the project as a whole and its coding efforts are commits. Figure 1, left, shows the distribution of total number of
consistent and reasonably efficient. While many Python commits per contributor as of early 2018. The relative flatness of
projects adopt a “Benevolent Dictator For Life” (BDFL) model, this distribution (as demonstrated by its log-log slope of −0.5)
Astropy has instead opted for a coordination committee. This is shows that the astropy core package has been developed by a
partly due to the nature of the project as a large-scale broad contributor base. A leading group of six developers have
collaboration between many contributors with many interests, each added over 1000 commits to the repository, and ∼20 more
and partly due to the sheer amount of work that needs to get core contributors have contributed at least 100 commits.
done. For the latter reason, the project has expanded the However, the distribution of contribution level (number of
committee from three to four members starting in 2016. commits) continues from 100 down to a single commit. In this
For resolving disagreements about the astropy core sense, the development of the core package has been a true
package or other Astropy-managed code, the coordination community effort and is not dominated by a single individual. It
committee primarily acts to work toward consensus, or when is also important to note that the number of commits is only a
consensus is difficult to achieve, generally acts as a “tie- rough metric of contribution, as any single commit could be a
breaker.” The committee also oversees affiliated package critical fix in the package or merely a fix for a typographical
applications to ensure that they are in keeping with Astropy’s error. Figure 1, middle, shows the number of commits as a
vision and philosophy,103 as well as the associated procedures. function of time since the genesis of the astropy core
Additionally, the committee oversees the assignment of roles package. The package is still healthy: new commits are and have
(primarily driven by already-existing contributions), and been contributed at a steady rate throughout its existence.
increasingly has acted as the “face” of the Project, providing Figure 1, right, shows that, ≈20–25 people contribute to the core
contact with organizations like NumFOCUS (the body that package each month. While we would like for this number to
holds any potential funding in trust for Astropy) and the grow, this demonstrates that the core package is still being
American Astronomical Society (AAS). developed and maintained by a substantial group of contributors.

2.2. Astropy Development Model 2.3. APEs—Astropy Proposals for Enhancement

Code is contributed to the astropy core package or The Astropy project has a formal mechanism to propose
modified through “pull requests” (via GitHub104) that often significant changes to the core package (e.g., re-writing the
contain several git commits. Pull requests may fix bugs, 105
How to make a code contribution,http://docs.astropy.org/en/latest/
102 development/workflow/development_workflow.html.
Codebase:https://github.com/astropy/astropy-v2.0-paper. 106
103 This line count includes comments, as these are often as important for
http://docs.astropy.org/en/stable/development/vision.html maintainability as the code itself. Without comments there are 142,197 lines
104
https://github.com/astropy/astropy/ of code.

4
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

coordinates subpackage; Tollerud et al. 2014), to plan out 2.5. Release Cycle and Long-term Support
major new features (e.g., a new file format; Aldcroft 2015), or
The astropy package has a regular release schedule
to institute new organization-wide policies (e.g., adopting a consisting of new significant releases every six months, with
code of conduct; Cruz et al. 2015). This mechanism is called bugfix releases as needed (Tollerud 2013). The major releases
“Astropy Proposal for Enhancement” (APE) and is modeled contain new features or any significant changes, whereas the
after the “Python Enhancement Proposals” (PEP) that guide the bugfix releases only contain fixes to code or documentation but
development of the Python programming language. In an no new features. Some versions are additionally designated as
APE, one or more authors describe in detail the proposed “Long-term support” (LTS) releases, which continue to receive
changes or additions, including a rationale for the changes, how bug fixes for two years following the release with no changes to
these changes will be implemented, and in the case of code, the API. The LTS versions are ideal for pipelines and other
what the interface will be (Greenfield 2013). The APEs are applications in which API stability is essential. The latest LTS
discussed and refined by the community before much work is release (version 2.0) is also the last one that supports Python 2;
invested into a detailed implementation; anyone is welcome to it will receive bug fixes until the end of 2019 (Robitaille 2017).
contribute to these discussions during the open consideration The version numbering of the astropy core package
period. APEs are proposed via pull requests on a dedicated reflects this release scheme: the core package version number
GitHub repository107; therefore, anyone can read the proposed uses the form x.y.z, where “x” is advanced for LTS releases,
APEs and leave in-line comments. When a community “y” for non-LTS feature releases, and “z” for bugfix releases.
consensus emerges, the APEs are accepted and become the This is similar to Semantic Versioning.108
basis for future work. In cases where consensus cannot be The released versions of the astropy core package are
reached, the Astropy coordination committee may decide to available from several of the Python distributions for
close the discussion and make an executive decision based on scientific computing (e.g.,Anaconda) and from the Python
Package Index (PyPI).109 Effort has been made to make
the community input on the APE in question.
astropy available and easily installable across all platforms;
the package is constantly tested on different platforms as part of
a suite of continuous integration tests.
2.4. Concept of Affiliated Packages
A major part of the Astropy Project is the concept of 2.6. Support of Astropy
“Affiliated Packages.” An affiliated package is an astronomy- The Astropy Project, as of the version 2.0 release, does not
related Python package that is not part of the astropy core receive any direct financial support for the development of
package, but has requested to be included as part of the Astropy astropy. Development of the software, all supporting
Project’s community. These packages support the goals and materials, and community support are provided by individuals
vision of Astropy of improving code re-use, interoperability, who work on the Astropy Project in their own personal time, by
and embracing good coding practices such as testing and individuals or groups contributing to Astropy as part of a
thorough documentation. research project, or contributions from institutions that allocate
Affiliated packages contain functionality that is more people to work on Astropy. A list of organizations that have
specialized, have license incompatibilities, or have external contributed to Astropy in this manner can be found in the
dependencies (e.g., GUI libraries) that make these packages Acknowledgments.
more suitable to be separate from the astropy core package. Different funding models have been proposed for support of
Affiliated packages may also be used to develop substantial Astropy (e.g., Muna et al. 2016), but a long-term plan for
new functionality that will eventually be incorporated into the sustainability has not yet been established. The Astropy Project
astropy core package (e.g., astropy.visualization.wcsaxes). has the ability to accept financial contributions from institutions
New functionality benefits from having a rapid development or individuals through the NumFOCUS110 organization.
and release cycle that is not tied to that of the astropy core NumFOCUS has, to date, covered the direct costs incurred
(Section 2.5). These projects may also have less stringent by the Astropy Project.
requirements for style, testing, or development as compared to
the core package. 2.7. Reuse of the Scientific Python Ecosystem
Affiliated packages are listed on the main Astropy website The Astropy Project is built on a philosophy of building
and advertised to the community through Astropy mailing lists; from the existing Python scientific ecosystem wherever
a list of current affiliated packages is included in Table 1. possible. Many of the enabling technologies like numpy,
Becoming an affiliated package is a good way for new and scipy, matplotlib, or cython, are necessary as the core
existing packages to gain exposure while promoting Astropy’s underpinnings of Astropy packages. Often, this means using
high standard for code and documentation quality. This process these packages as “building blocks” (e.g., the ubiquitous use of
of listing and promoting affiliated packages is one way in numpy arrays throughout astropy). In other cases, this
which the Astropy Project tries to increase code re-use in the means wrappers around more general algorithms that make
astronomical community. them more convenient for astronomy use cases (e.g., the
Packages can become affiliated with Astropy by applying for model-fitting in the astropy.modeling subpackage
this status on a public mailing list. The coordination committee 108
https://semver.org
(Section 2.1) reviews such requests and issues recommenda- 109
See the installation documentation for more information:http://docs.
tions for the improvement of a package, where applicable. astropy.org/en/stable/install.html.
110
NumFOCUS is a 501(c)(3) nonprofit that supports and promotes world-
107
https://github.com/astropy/astropy-APEs class, innovative, open-source scientific computing.

5
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

discussed in Section 3.7). Sometimes these simple wrappers The motivation and key concepts behind this subpackage
evolve into more complex implementations that address were described in detail in the previous paper (Astropy
astronomically relevant use cases the general tool does not Collaboration et al. 2013). Therefore, we primarily highlight
support (e.g., astropy.convolution, see Section 3.8). As new features and improvements here.
a broad rule, the Project explicitly encourages re-use of code
where possible.
However, the boundaries of when this re-use is called for is 3.1.1. Interaction with numpy Arrays
often ambiguous. Some of the examples above only evolved
Quantity objects extend numpy.ndarray objects and
after significant debate in the community over whether these
therefore work well with many of the functions in numpy that
algorithms were sufficient. Other times, even apparently
support array operations. For example, Quantity objects with
general functionality did not exist in the wider ecosystem that
angular units can be directly passed in to the trigonometric
met the Astropy community’s needs, and hence the function-
functions implemented in numpy. The units are internally
ality had to be developed wholly from the developer resources
converted to radians, which is what the numpy trigonometric
available in the community (e.g., astropy.units, or
functions expect, before being passed to numpy.
astropy.table when it began). At the same time, however,
the Astropy Project has provided the wider community with
myriad bug fixes to the enabling technologies listed above, as
3.1.2. Logarithmic Units and Magnitudes
well as the testing and documentation architecture. Function-
ality is only “extracted” from Astropy to other packages after By default, taking the logarithm of a Quantity object with non-
careful consideration that includes considering the impact on dimensionless units intentionally fails. However, some well-known
the maintenance and support of Astropy. units are actually logarithmic quantities, where the logarithm of the
value is taken with respect to some reference value. Examples
include astronomical magnitudes, which are logarithmic fluxes,
3. Astropy Core Package Version 2.0 and decibels, which are more generic logarithmic ratios of
quantities. Logarithmic, relative units are now supported in
The Astropy Project aims to provide Python-based
astropy.units.
packages for all tasks that are commonly needed in a large
subset of the astronomical community. At the foundation is the
astropy core package, which provides general functionality
3.1.3. Defining Functions that Require Quantities
(e.g., coordinate transformations, reading and writing astro-
nomical files, and units) or base classes for other packages to When writing code or functions that expect Quantity objects,
utilize for a common interface (e.g.,NDData). In this section, we often want to enforce that the input units have the correct
we highlight new features introduced or substantially improved physical type. For example, we may want to require only
since version 0.2 (previously described in Astropy Collabora- length-type Quantity objects. astropy.units provides a tool
tion et al. 2013). The astropy package provides a full log of calledquantity_input() that can perform this verification
changes111 over the course of the entire project and more automatically to avoid repetitive code.
details about individual subpackages are available in the
documentation.112 Beyond what is mentioned below, most
subpackages have seen improved performance since the release 3.2. Constants
of the version 0.2 package.
The astropy.constants subpackage provides a selection of
physical and astronomical constants as Quantity objects (see
Section 3.1). A brief description of this package was given in
3.1. Units
Astropy Collaboration et al. (2013). In version 2.0, the built-in
The astropy.units subpackage adds support for representing constants have been organized into modules for specific
units and numbers with associated units—“quantities”—in versions of the constant values. For example, physical
code. Historically, quantities in code have often been constants have codata2014 (Mohr et al. 2016) and
represented simply as numbers, with units implied or noted codata2010 versions. Astronomical constants are organized
via comments in the code because of considerations about into iau2015 and iau2012 modules to indicate their sources
speed: having units associated with numbers inherently adds (resolutions from the International Astronomical Union, IAU).
overhead to numerical operations. In astropy.units, Quantity The codata2014 and iau2015 versions are combined into
objects extend numpy array objects and have been designed the default constant value version: astropyconst20. For
with speed in mind. compatibility with astropy version 1.3, astropyconst13
As of astropy version 2.0, units and quantities, prevalent is available and provides access to the adopted versions of the
in most of its subpackages, have become a key concept for constants from earlier versions of astropy. To use previous
using the package as a whole. Units are intimately entwined in versions of the constants as units (e.g., solar masses), the values
the definition of astronomical coordinates; thus, nearly all have to be imported directly; with version 2.0, astropy.units
functionality in the astropy.coordinates subpackage (see uses the astropyconst20 versions.
Section 3.3) depends on them. Most astropy subpackages Astronomers using astropy.constants should take particular
have been made compatible with Quantity objects, although note of the constants provided for Earth, Jupiter, and the Sun.
they are not always required. Following IAU 2015 Resolution B3 (Mamajek et al. 2015),
nominal values are now given for mass parameters and radii.
111
https://github.com/astropy/astropy/blob/stable/CHANGES.rst The nominal values will not change even as “current best
112
http://docs.astropy.org/en/stable/ estimates” are updated.

6
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 2. The full graph of possible reference frame transformations implemented in astropy.coordinates. Arrows indicate transformations from one frame to another.
Arrows that point back to the same frame indicate self-transformations that involve a change of reference frame parameters (e.g., equinox).

3.3. Coordinates angles are right ascension (ra) and declination (dec), whereas
in the Galactic frame, the spherical angles are Galactic
The astropy.coordinates subpackage is designed to support
longitude (l) and latitude (b). Each Frame class defines its
representing and transforming celestial coordinates and—new
in version 2.0—velocities. The framework heavily relies on the own component names and preferred Representation
astropy.units subpackage, and most inputs to objects in this class. The frame-specific component names map to corresp-
subpackage are expected to be Quantity objects. Some of the onding components on the underlying Representation
machinery also relies on the Essential Routines of Fundamental object that internally stores the coordinate data. For most
Astronomy (ERFA) C library for some of the critical under- frames, the preferred representation is spherical, although this
lying transformation machinery (Tollerud et al. 2017), which is is determined primarily by their common use in the
based on the Standards Of Fundamental Astronomy (SOFA) astronomical community.
effort (Hohenkerk 2011). Many of the Frame classes also have attributes specific to
A key concept behind the design of this subpackage is that the corresponding reference system that allow the user to
coordinate representations and reference systems/frames are specify the frame. For example, the Fifth Fundamental
independent of one another. For example, a set of coordinates Catalogue (FK5) reference system requires specifying an
in the International Celestial Reference System (ICRS) equinox to determine the reference frame. If required, these
reference frame could be represented as spherical (right additional frame attributes must be specified, along with the
ascension, declination, and distance from solar system coordinate data, when a Frame object is created. Figure 2
barycenter) or Cartesian coordinates (x, y, z with the origin at shows the network of possible reference frame transformations
barycenter). They can therefore change representations inde- as currently implemented in astropy.coordinates. Custom user-
pendent of being transformed to other reference frames (e.g., implemented Frame classes that define transformations to any
the Galactic coordinate frame). reference frame in this graph can then be transformed to any of
The classes that handle coordinate representations (the the other connected frames.
Representation classes) act like three-dimensional vectors The typical user does not usually have to interact directly
and thus support vector arithmetic. The classes that represent with the Frame or Representation classes. Instead,
reference systems and frames (the Frame classes) internally astropy.coordinates provides a high-level interface to represent-
use Representation objects to store the coordinate data— ing astronomical coordinates through the SkyCoord class,
that is, the Frame classes accept coordinate data, either as a which was designed to provide a single class that accepts a
specified Representation object, or using short-hand wide range of possible inputs. It supports coordinate data in any
keyword arguments to specify the components of the coordinate frame in any representation by internally using the
coordinates. These preferred representation and short-hand Frame and Representation classes.
component names differ between various astronomical refer- In what follows, we briefly highlight key new features in
ence systems. For example, in the ICRS frame, the spherical astropy.coordinates.

7
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

3.3.1. Local Earth Coordinate Frames The benchmarks are meant to evolve over time and include
an increasing variety of cases. At the moment, the benchmarks
In addition to representing celestial coordinates, astropy
now supports specifying positions on the Earth in a number of are set up as follows—we have generated a standard set of
different geocentric systems with the EarthLocation class. 1000 pairs of random longitudes/latitudes that we use in all
With this, astropy now supports Earth-location-specific benchmarks. Each benchmark is then defined using an input
coordinate systems such as the altitude-azimuth (AltAz) or and output coordinate frame, using all combinations of FK4,
horizontal system. Transformations between AltAz and any FK5, Galactic, ICRS, and Ecliptic frames. For now, we set the
Barycentric coordinate frame also requires specifying a time epoch of observation to J2000. We also set the frame to J2000
using the Time class from astropy.time. With this new (for FK5 and Ecliptic) and B1950 (for FK4). In the future, we
functionality, many of the common tasks associated with plan to include a larger variety of epochs and equinoxes, as
observation planning can now be completed with astropy or well as tests of conversion to/from Altitude/Azimuth. For each
the Astropy-affiliated package astroplan (Morris et al. 2018). benchmark, we convert the 1000 longitudes/latitudes from the
input/output frame with all tools and quantify the comparison
3.3.2. Proper Motion and Velocity Transformations by looking at the median, mean, maximum, and standard
deviation of the absolute separation of the output coordinates
In addition to positional coordinate data, the Frame classes from each pair of tools.
now also support velocity data. As the default representation Figure 3 visualizes the relative accuracy of the conversion
for most frames is spherical, most of the Frame classes expect from FK4 to Galactic coordinates for all pairs of tools that
proper motion and radial velocity components to specify the implement this transformation. In this figure, the color of the
velocity information. The names of the proper motion cell indicates the maximum difference (in arcseconds) between
components all start with pm and adopt the same longitude the two tools over the 1000 longitude-latitude pairs tested. This
and latitude names as the positional components. Transforming figure shows, for example, that astropy, Kapteyn, and
coordinates with velocity data is also supported, but in some PyTPM agree with sub-milliarcsecond differences (light colors,
cases the transformed velocity components have limited small differences), while PALpy, pySLALIB, and PyAST also
accuracy because the transformations are done numerically
agree among themselves. However, there is an offset of around
instead of analytically. The low-level interface for specifying
0 2 between the two groups. Finally, PyEphem disagrees with
and transforming velocity data is currently experimental. As
such, in version 2.0, only the Frame classes (and not the all other packages by 0 4–0 8 (darker colors, large differ-
SkyCoord class) support handling velocities. ences). These values are only meant to be illustrative and will
change over time as the benchmarks are refined and the
packages updated.
3.3.3. Solar System Ephemerides
Also new is support for computing ephemerides of major
solar system bodies and outputting the resulting positions as 3.4. Time
coordinate objects. These ephemerides can be computed either The astropy.time subpackage focuses on supporting time-
using analytic approximations from ERFA or from downloaded scales (e.g., UTC, TAI, UT1) and time formats (e.g., Julian
JPL ephemerides (the latter requires the jplephem113
date, modified Julian date) that are commonly used in
optional dependency and an internet connection).
astronomy. This functionality is needed, for example, to
calculate barycentric corrections or sidereal times. astropy.
3.3.4. Accuracy of Coordinate Transformations time is currently built on the ERFA (Tollerud et al. 2017) C
In order to check the accuracy of the coordinate transforma- library, which replicates the Standards of Fundamental
tions in astropy.coordinates, we have created a set of bench- Astronomy (SOFA; Hohenkerk 2011) but is licensed under a
marks that we use to compare transformations between a set of three-clause BSD license. The package was described in detail
coordinate frames for a number of packages.114 Because no in Astropy Collaboration et al. (2013) and has remained stable
package can be guaranteed to implement all transformations to for the last several versions of astropy. Thus, in what
arbitrary precision and some transformations are sometimes follows, we only highlight significant changes or new features
subject to interpretation of standards (particularly in the case of since the previous Astropy paper.
Galactic coordinates), we do not designate any of the existing
packages as the “ground truth” but instead compare each tool to
all other tools. The benchmarks are thus useful beyond the 3.4.1. Barycentric and Heliocentric Corrections
Astropy Project because they allow all of the tools to be
compared to all other tools. The tools included in the Detailed eclipse or transit timing requires accounting for
benchmark at the moment include the astropy core package, light traveltime differences from the source to the observatory
Kapteyn (Terlouw & Vogelaar 2015), NOVAS (Barron et al. because of the Earth’s motion. It is therefore common to
2011), PALpy (Jenness & Berry 2013), PyAST (a wrapper for instead convert times to the solar system barycenter or
AST, described in Berry et al. 2016), PyTPM,115 PyEphem heliocenter where the relative timing of photons is standar-
(Rhodes 2011), and pySLALIB (a Python wrapper for dized. With the location of a source on the sky (i.e., a
SLALIB, described in Wallace 1994). SkyCoord object), the location of an observatory on Earth (i.e.,
anEarthLocation object), and time values as Time objects, the
113 time corrections to shift to the solar system barycenter or
https://github.com/brandon-rhodes/python-jplephem
114
http://www.astropy.org/coordinates-benchmark/summary.html heliocenter can now be computed with astropy.time using the
115
https://github.com/phn/pytpm light_travel_time method of a Time object.

8
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 3. Comparison matrix of the maximum difference between longitude-latitude values in a set of 1000 random points transformed from FK4 to Galactic with the
different packages. Darker colors (larger differences) are more significant disagreements.

3.5. Data Containers The http://docs.astropy.org/en/stable/nddata/utils.html

astropy.nddata.utils module provides utilities that
3.5.1. nddata
can operate on either plain numpy arrays or any of the
The astropy.nddata subpackage provides three types of classes in the astropy.nddata subpackage. It features a class
functionality: an abstract interface for representing generic for representing two-dimensional image cutouts, allowing
arbitrary-dimensional data sets intended primarily for subclassing one to easily link pixels in the cutout to those in the original
by developers of other packages, concrete classes building on this image or vice versa, to convert between world and pixel
interface, and utilities for manipulating these kind of data sets. coordinates in the cutout, and to overlay the cutout on
The NDDataBase class provides the abstract interface for images. Functions to enlarge or reduce an image by doing
gridded data with attributes for accessing metadata, the world block replication or reduction are also provided.
coordinate system (WCS), uncertainty arrays matched to the
shape of the data, and other traits. Building on this interface, the
NDData class provides a minimal working implementation for 3.5.2. Tables
storing numpy arrays. These classes serve as useful base classes
for package authors wishing to develop their own classes for The astropy.table subpackage provides functionality for
specific use cases and as containers for exchanging gridded data. representing and manipulating heterogeneous data. In some
The classes NDDataRef, NDDataArray, and CCDData respects, this is similar to numpy record arrays (Van der Walt
extend the base storage functionality with options to do basic et al. 2011) or pandas DataFrame objects (McKinney 2010),
arithmetic (addition, subtraction, multiplication, and division), but with modifications for astronomical data. Most notably,
including error propagation in limited cases, and slicing of the tables from astropy.table allow for table or column metadata and
data set based on grid coordinates that appropriately handles can handle vectors/arrays or arbitrary objects (with suitable
masking, errors, and units (if present). Additionally, the column-like characteristics) as table entries. The subpackage was
CCDData class also provides reading and writing from and described in detail in Astropy Collaboration et al. (2013). Thus,
to FITS files, and uses data structures from astropy, like in what follows, we only summarize key new features or updates
WCS, to represent the file contents abstractly. to astropy.table since the previous Astropy paper. These are

9
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

support for grouped table operations, table concatenation, and format makes it possible to write a table to an ASCII-format file
using array-valued astropy objects as table columns. and read it back with no loss of information. The ECSV format
A table can contain data that naturally form groups; for has been designed to be both human-readable and compatible
example, it may contain multiple observations of a few sources with most simple CSV readers.
at different points in time and in different bands. We may want The astropy.io.ascii subpackage now includes a significantly
to split the table into groups based on the combination of faster Cython/C engine for reading and writing ASCII files.
source observed and the band, after which we combine the This is available for most of the common formats. It also offers
results for each combination of source and band in some way some additional features like parsing of different exponential
(e.g., finding the mean or standard deviation of the fluxes or notation styles, such as commonly produced by Fortran
magnitudes over time) or filter the groups based on user- programs. On average, the new engine is about four to five
defined criteria. These kinds of grouping and aggregation times faster than the corresponding pure-Python implementa-
operations are now fully supported by Table objects. tion and is often comparable to the speed of the pandas
Table objects can now be combined in several different (McKinney 2010) ASCII file interface. The fast reader has a
ways. If two tables have the same columns, we may want to parallel processing option that allows harnessing multiple cores
stack them “vertically” to create a new table with the same for input parsing to achieve even greater speed gains. By
columns but all rows. If two tables are row-matched but have default, read() and write() will attempt to use the fast
distinct columns, we may want to stack them “horizontally” to Cython/C engine when dealing with compatible formats.
create a new table with the same rows but all columns. For Certain features of the full read / write interface are unavailable
other situations, more generic table concatenation or joining are in the fast version, in which case the reader will by default fall
also possible when two tables share some columns. back automatically to the pure-Python version.
The Table object now allows array-valued Quantity, celestial The astropy.io.ascii subpackage now provides the capability
coordinate (SkyCoord), and date/time (Time) objects to be used to read a table within an HTML file or web URL into an
as columns. It also provides a general way for other user-defined astropy Table object. A Table object can now also be
array-like objects to be used as columns. This makes it possible, written out as an HTML table.
for instance, to easily represent catalogs of sources or time series
in Astropy, while having both the benefits of the Table object 3.6.2. FITS
(e.g., accessing specific rows/columns or groups of them and
combining tables) as well as, for example, the SkyCoord or the The astropy.io.fits subpackage started as a direct port of the
Time classes (e.g., converting the coordinates to a different PyFITS project (Barrett & Bridgman 1999). Therefore, it is pretty
frame or accessing the date/time in the desired timescale). stable, with mostly bug fixes but also a few new features and
Additionally, there is now interoperability between Table performance improvements. The API remains mostly compatible
and pandas DataFrame objects using the Table. with PyFITS, which is now deprecated in favor of astropy.
to_pandas() and Table.from_pandas() methods. Command-line scripts are now available for printing a
Table.to_pandas() is, however, limited to a subset of summary of the HDUs in FITS file(s) (fitsinfo) and for printing
possible Table objects, because several of the features the header information to the screen in a human-readable
outlined above cannot be represented as pandas data frames. format (fitsheader).
While these features might be contributed to or combined with FITS files are now loaded lazily by default, i.e., an object
pandas at a later date, the architectural differences that enable representing the list of HDUs is created but the data are not
these areas are significant, so this would be a major undertaking loaded into memory until requested. This approach should
that would require substantial investment from the core provide substantial speed-ups when using the convenience
maintainers and communities of both packages. functions (e.g.,getheader() orgetdata()) to get an HDU that is
near the beginning in a file with many HDUs.

3.6. io 3.6.3. HDF5

The astropy.io subpackages provide support for reading The astropy.io.misc.hdf5 subpackage provides
and writing data to a variety of ASCII and binary file formats, support for binary read and write access to files in the
such as a wide range of ASCII data table formats, FITS, HDF5, Hierarchical Data Format (HDF5), if the h5py package is
and VOTable. It also provides a unified interface for reading installed. Astropy table I/O is offered transparently through
and writing data with these different formats using the astropy. Table.read() and Table.write(), analogously to the
table subpackage. For many common cases, this simplifies the other auto-detected formats. The keyword path=’group/
process of file input and output (I/O) and reduces the need to subgroup/data set’ specifies the path to the data inside
master the separate details of all the I/O packages within the file’s hierarchical structure.
astropy. The file interface allows transparent compression of
the gzip, bzip2, and lzma (.xz) formats; the latter two
3.7. Modeling
require the Python installation to have been compiled with
support the respective libraries. The astropy.modeling subpackage provides a framework for
representing analytical models and performing model evalua-
tion and parameter fitting. The main motivation for this
3.6.1. ASCII
functionality was to create a framework that allows arbitrary
One of the problems when storing a table in an ASCII format combination of models to support the Generalized World
is preserving table metadata such as comments, keywords and Coordinate System (GWCS) package.116 The current FITS
column data types, units, and descriptions. The newly defined
Enhanced Character Separated Values (ECSV, Aldcroft 2015) 116
https://github.com/spacetelescope/gwcs

10
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

WCS specification lacks the flexibility to represent arbitrary 3.7.4. Fitting Models to Data
distortions and does not meet the needs of many types of
The astropy.modeling subpackage also provides several
current instrumentation. The fact that the astropy modeling
fitters that are wrappers around some of the numpy and
framework now supports propagating units also makes it a
scipy.optimize functions and provide support for speci-
useful tool for representing and fitting astrophysical models
fying parameter constraints. The fitters take a model and data as
within data analysis tools.
input and return a copy of the model with the optimized
Models and fitters are independent of each other: a model
parameter values set. The goal is to make it easy to extend the
can be fit with different fitters and new fitters can be added
fitting framework to create new fitters. The optimizers available
without changing existing models. The framework is designed
in astropy version 2.0 are Levenberg–Marquardt (scipy.
to be flexible and easily extensible. The goal is to have a rich
optimize.leastsq), Simplex (scipy.optimize.
set of models, but also facilitate creating new ones, if
fmin), SLSQP (scipy.optimize.slsqp), and Linear-
necessary.
LSQFitter (numpy.linalg.lstsq which provides exact
solutions for linear models).
3.7.1. Single Model Definition and Evaluation Modeling also supports a plugin system for fitters, which
Models are defined by their parameters and initialized by allows using the astropy models with external fitters. An
providing values for them. The names of the parameters are example of this is SABA,117 which is a bridge between Sherpa
stored in a list, Model.param_names. Parameters are (Doe et al. 2007), and astropy.modeling, to bring the Sherpa
complex objects. They store additional information—default fitters into astropy.
value, default unit, and parameter constraints. Parameter values
and constraints can be updated by assignment. Supported 3.7.5. Creating New Models
constraints include fixed and tied parameters, as well as If arithmetic combinations of existing models are not
bounds on parameter values. The framework also supports sufficient, new model classes can be defined in different ways.
models for which the number of parameters and their names are The astropy.modeling package provides tools to turn a simple
defined by another argument. A typical example is a function into a full-featured model, but it also allows extending
polynomial model defined by its degree. A model is evaluated the built-in model class with arbitrary code.
by calling it as a function.
If an analytical inverse of a model exists, it can be accessed
3.7.6. Unit Support
by calling Model.inverse. In addition, Model.inverse
can be assigned another model that represents a computed The astropy.modeling subpackage now supports the repre-
inverse. sentation, evaluation, and fitting of models using Quantity
Another useful settable property of models is Model. objects, which attach units to scalar values or arrays of values.
bounding_box. This attribute sets the domain over which In practice, this means that one can, for example, fit a model to
the model is defined. This greatly improves the efficiency of data with units and get parameters that also have units out, or
evaluation when the input range is much larger than the initialize a model with parameters with units and evaluate it
characteristic width of the model itself. using input values with different but equivalent units. For
example, the blackbody model (BlackBody1D) can be used to
3.7.2. Model Sets fit observed flux densities in a variety of units and as a function
of different units of spectral coordinates (e.g., wavelength or
Using astropy.modeling provides an efficient way to set up the frequency).
same type of model with many different sets of parameter
values. This creates a model set that can be efficiently evaluated.
3.8. Convolution
For example, in PSF (point-spread function) photometry, all
objects in an image will have a PSF of the same functional form, The astropy.convolution subpackage implements normalized
but with different positions and amplitudes. convolution (e.g., Knutsson & Westin 1993), an image
reconstruction technique in which missing data are ignored
3.7.3. Compound Models during the convolution and replaced with values interpolated
using the kernel. An example is given in Figure 4. In astropy
Models can be combined using arithmetic expressions. The versions „1.3, the direct convolution and Fast Fourier
result is also a model, which can further be combined with Transform (FFT) convolution approaches were inconsistent,
other models. Modeling supports arithmetic (+, −, *, /, and **), with only the latter implementing normalized convolution. As
join (&), and composition (|) operators. The rules for of version 2.0, the two methods now agree and include a suite
combining models involve matching their inputs and outputs. of consistency checks.
For example, the composition operator, |, requires the number
of outputs of the left model to be equal to the number of inputs
3.9. Visualization
of the right one. For the join operator, the total number of
inputs must equal the sum of number of inputs of both the left The astropy.visualization subpackage provides functionality
and the right models. For all arithmetic operators, the left and that can be helpful when visualizing data. This includes a
the right models must have the same number of inputs and framework (previously the standalone astropy.visualization.
outputs. An example of a compound model could be a wcsaxes package) for plotting astronomical images with
spectrum with interstellar absorption. The stellar spectrum and coordinates via matplotlib, functionality related to image
the interstellar extinction are represented by separate models, normalization (including both scaling and stretching), smart
but the observed spectrum is fitted with a compound model that
117
combines both. https://github.com/astropy/saba

11
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 4. An example showing different modes of convolution available in the Python ecosystem. Each red x signifies a pixel that is set to NaN in the original data
(top left). If the data are convolved with a Gaussian kernel on a 9×9 grid using scipy’s direct convolution (top right), any pixel within range of the original NaN
pixels is also set to NaN. The bottom left panel shows what happens if the NaNs are set to zero first: the original NaN regions are depressed relative to their
surroundings. Finally, the bottom right panel shows astropy’s convolution behavior, where the missing pixels are replaced with values interpolated from their
surroundings using the convolution kernel.

histogram plotting, red-green-blue (RGB) color image creation Stretching transforms the image values in the range
from separate images, and custom plotting styles for [0, 1] again to the range [0, 1], using a linear or nonlinear
matplotlib. function:

3.9.1. Image Stretching and Normalization

z = f ( y ). (2 )
Using astropy.visualization provides a framework for trans-
forming values in images (and more generally, any arrays),
Several classes are provided for automatically determining
typically for the purpose of visualization. The two main types of
intervals (e.g., using image percentiles) and for normalizing
transformations are normalization and stretching of image values.
values in this interval to the [0, 1] range.
Normalization transforms the image values to the range [0, 1]
Using matplotlib allows a custom normalization and
using lower and upper limits (vmin, vmax),
stretch to be used when displaying data by passing in a
x - vmin normalization object. The astropy.visualization package also
y= , (1 )
vmax - vmin provides a normalization class that wraps the interval and
stretches objects into a normalization object that matplotlib
where x represents the values in the original image. understands.

12
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 5. An example of a figure made using the astropy.visualization.wcsaxes subpackage, using Spitzer/IRAC 8.0μm data from the Cygnus-X Spitzer Legacy
survey (Beerer et al. 2010).

3.9.2. Plotting Image Data with World Coordinates interface that is much closer to that of matplotlib (Hunter
2007). This enables significantly more advanced visualizations.
Astronomers dealing with observational imaging commonly
An example of a visualization made with astropy.
need to make figures with images that include the correct visualization.wcsaxes is shown in Figure 5. This example
coordinates and optionally display a coordinate grid. The illustrates the ability to overlay multiple coordinate systems and
challenge, however, is that the conceptual coordinate axes customize which ticks/labels are shown on which axes around
(such as longitude/latitude) need not be lined up with the pixel the image. This also uses the image stretching functionality
axes of the image. The astropy.visualization.wcsaxes subpack- from Section 3.9.1 to show the image in a square-root stretch
age implements a generalized way of making figures from an (automatically updating the tick positions in the colorbar).
image array and a WCS object that provides the transformation
between pixel and world coordinates.
World coordinates can be, for example, right ascension and 3.9.3. Choosing Histogram Bins
declination, but can also include, for example, velocity,
The astropy.visualization subpackage also provides a
wavelength, frequency, or time. The main features from this
histogram function, which is a generalization of matplo-
subpackage include the ability to control which axes to show tlib’s histogram function, to allow for a more flexible
which coordinate on (e.g., showing longitude ticks on the top specification of histogram bins. The function provides several
and bottom axes and latitude on the left and right axes), methods of automatically tuning the histogram bin size. It has a
controlling the spacing of the ticks either by specifying the syntax identical to matplotlibʼs histogram function, with
positions to use or providing a tick spacing or an average the exception of the bins parameter, which allows specifica-
number of ticks that should be present on each axis, setting the tion of one of four different methods for automatic bin
format for the tick labels to ones commonly used by selection: “blocks,” “knuth,” “scott,” or “freedman.”
astronomers, controlling the visibility of the grid/graticule,
and overlaying ticks, labels, and/or grid lines from different
coordinate systems. In addition, it is possible to pass data with 3.9.4. Creating Color RGB Images
more than two dimensions and slice on-the-fly. Last but not Lupton et al. (2004) describe an “optimal” algorithm for
least, it is also able to define non-rectangular frames such as, producing RGB composite images from three separate high-
for example, Aitoff projections. dynamic range arrays. The astropy.visualization subpackage
This subpackage differs from APLpy (Robitaille & Bressert provides a convenience function to create such a color image. It
2012), in that the latter focuses on providing a very high-level also includes an associated set of classes to provide alternate
interface to plotting that requires very few lines of code to get a scalings. This functionality was contributed by developers from
good result, whereas astropy.visualization.wcsaxes defines an the Large Synoptic Survey Telescope (LSST) and serves as an

13
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 6. An RGB color image of the region near the Hickson 88 group constructed from SDSS images and the astropy.visualization tools. This example uses
astropy.visualization.wcsaxes to display the sky coordinate grid, and thehttp://docs.astropy.org/en/stable/api/astropy.visualization.make_lupton_rgb.html
make_lupton_rgb() function to produce the RGB image from three SDSS filter images (g, r, i). The image on the left shows the image with the default
parameters, whereas the image on the right has parameters set to show a greater dynamical range.

example of a contribution to Astropy from a more traditional 3.11.2. Circular Statistics

engineering organization (Jenness et al. 2016).
Astronomers often need to compute statistics of quantities
The Sloan Digital Sky Survey (SDSS) SkyServer color
evaluated on a circle, such as sky direction or polarization
images were made using a variation on this technique. As an
angle. A set of circular statistical estimators based on
example, in Figure 6, we show an RGB color image of the
Jammalamadaka & Sengupta (2001) are implemented in
Hickson 88 group, centered near NGC6977.118 This image
astropy.stats. These functions provide measurements of the
was generated from SDSS images using the astropy.
circular mean, variance, and moment. All of these functions
visualization tools.
work with both numpy.ndarrays (assumed to be in radians)
and Quantity objects. In addition, the subpackage includes tests
3.10. Cosmology for Rayleigh Test, vtest, and a function to compute the
The astropy.cosmology subpackage contains classes for maximum likelihood estimator for the parameters of the von
representing different cosmologies and functions for calculat- Mises distribution.
ing commonly used quantities such as look-back time and
distance. The subpackage was described in detail in Astropy 3.11.3. Lomb–Scargle Periodograms
Collaboration et al. (2013). The default cosmology in
astropy version 2.0 is given by the values in Planck Periodic analysis of unevenly spaced time series is common
Collaboration et al. (2016). across many subfields of astronomy. The astropy.stats package
now includes several efficient implementations of the Lomb–
Scargle periodogram (Lomb 1976; Scargle 1982) and several
3.11. Statistics generalizations, including floating mean models (Zechmeister &
The astropy.stats package provides statistical tools that are Kürster 2009), truncated Fourier models (Bretthorst 2003), and
useful for astronomy and are either not found in or extend the appropriate handling of heteroscedastic uncertainties. Impor-
available functionality of other Python statistics packages, tantly, the implementations make use of several fast and scalable
such as scipy (Jones et al. 2001) or statsmodels (Seabold computational approaches (e.g., Press & Rybicki 1989; Palmer
& Perktold 2010). The astropy.stats package also contains a 2009), and thus can be applied to much larger data sets than
range of functionality used by many different disciplines in Lomb–Scargle algorithms available in, e.g., scipy.stats
astronomy. It is not a complete set of statistical tools, but rather (Jones et al. 2001). Much of the Lomb–Scargle code in
a still growing collection of useful features. astropy has been adapted from previously published open-
source code (VanderPlas et al. 2012; VanderPlas & Ivezic 2015).
Users should be aware that correct interpretation of periodogram
3.11.1. Robust Statistical Estimators results involves some subtleties; for a thorough discussion of this
Robust statistics provide reliable estimates of basic statistics issue, see (VanderPlas 2018, in press).
for complex distributions that largely mitigate the effects of
outliers. The astropy.stats package includes several robust 3.11.4. Bayesian Blocks and Histogram Binning
statistical functions that are commonly used in astronomy, such
as sigma clipping methods for rejecting outliers, median The astropy.stats package also includes an implementation of
absolute deviation functions, and biweight estimators, which Bayesian Blocks (Scargle et al. 2013), an algorithm for analysis of
have been used to calculate the velocity dispersion of galaxy breakpoints in nonperiodic astronomical time-series. One inter-
clusters (Beers et al. 1990). esting application of Bayesian Blocks is its use in determining
optimal histogram binnings, particularly binnings with unequal
118
http://skyserver.sdss.org/dr13/en/tools/chart/navi.aspx?ra=313. bin sizes. This code was adapted, with several improvements,
12381&dec=-5.74611 from the astroML package (VanderPlas et al. 2012). An

14
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Figure 7. Three approaches to a 1D histogram. Left: a standard histogram using matplotlib’s default of 10 bins. Center: a histogram with the number of equal-width
bins determined automatically using numpy’s bins=’auto’. Right: a histogram created by astropy, with irregularly spaced bins computed via the Bayesian
Blocks algorithm. Compared to regularly spaced bins, the irregular bin widths give a more accurate visual representation of features in the data set at various scales.

example of a histogram fit using the Bayesian Blocks algorithm is 4.3. Sphinx Extensions
shown in the right panel of Figure 7.
The documentation for many Python packages, including all
the packages in the Astropy ecosystem, is written using the
Sphinx documentation build system. Sphinx supports writing
4. Infrastructure for Astropy Affiliated Packages
documentation using plain text files that follow a markup
In addition to astronomy-specific packages and libraries, the language called reStructuredText (RST). These files are
Astropy Project also maintains and distributes several general- then transformed into HTML, PDF, or LATEX documents
purpose infrastructure packages that assist with the maintenance during the documentation build process. For the Astropy Project,
and upkeep of the astropy core package and other affiliated we have developed several Sphinx extensions that facilitate
packages. The following sections describe the most widely used automatically generating API documentation for large projects,
infrastructure packages developed by the Astropy Project. like the astropy core package. The main extension we have
developed is sphinx-automodapi,124 which provides a
convenient single RST command to generate a set of
4.1. Package Template documentation pages, listing all of the available classes,
functions, and attributes in a given Python module.
Astropy provides a package template—as a separate GitHub
repository, astropy/package-template119—that aims to
simplify setting up packaging, testing, and documentation builds 5. The Future of the Astropy Project
for developers of affiliated packages or astropy-dependent Following the release of version 2.0, development on the
packages. Any Python package can make use of this ready-to- next major version of the astropy core package (version 3.0)
go package layout, setup, installation, and Sphinx documenta- began. On top of planned changes and additions to the core
tion build infrastructure that was originally developed for the package, we also plan to overhaul the Astropy educational/
astropy core package and affiliated packages maintained by learning materials and further generalize the infrastructure
the Astropy Project. The package template also provides a utilities originally developed for the core package for the
testing framework, template configurations for continuous benefit of the community.
integration services, and Cython build support.
5.1. Future Versions of the Astropy Core and Affiliated
Packages
4.2. Continuous Integration Helpers
One of the most significant changes coming in this next
Astropy also provides a set of scripts for setting up and major release will be removing the support for Python 2
configuring continuous integration (CI) services as a GitHub (Robitaille 2017): future versions of astropy will only
repository, astropy/ci-helpers.120 These tools aim to support Python 3.5 or higher. Removing Python 2 support
enable package maintainers to control their testing setup and will allow the use of new features exclusive to Python 3,
installation process for various CI services through a set of simplify the code base, and reduce the testing overhead for the
environment variables. While the current development is package. Version 3.0 was released in February 2018.
mostly driven by the needs of the Astropy ecosystem, the In the next major release after version 3.0, scheduled for
actual usage of this package is extremely widespread.121 The mid-2018, the focus will be on algorithm optimization and
current tools support configuration for Travis CI122 and documentation improvement. To prepare for this release, we
Appveyor CI.123 are subjecting the core package to testing, evaluation, and
119
performance monitoring. As a result, less new functionality
https://github.com/astropy/package-template/ may be introduced, as a trade-off for better performance.
120
https://github.com/astropy/ci-helpers
121 Beyond the core code, the Astropy Project is also further
Approximately 30% of the ci-helpers contributors come from outside the
astropy community, and there are currently 292 repositories on github that have developing the Astropy-managed affiliated packages. While
ci-helpers in their travis configuration file. these may not be integrated into the astropy core package,
122
https://travis-ci.org/
123 124
https://www.appveyor.com/ http://sphinx-automodapi.readthedocs.io

15
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

these projects provide code that is useful to the astronomical standards helps users to trust the calculations performed with
community and meet the testing and documentation standards astropy and to publish reproducible results. At the same time,
of Astropy. Some of these new efforts include an initiative to the Astropy ecosystem and core package are both growing: new
develop tools for spectroscopy (Crawford et al. 2017, spec- functionality is still being contributed and new affiliated
utils, specreduc, specviz), integration of LSST soft- packages are being developed to support more specialized needs.
ware, and support for HEALPIX projection. The Astropy Project is also spreading awareness of best
practices in community-driven software development. This is
5.2. Learn Astropy important because most practicing astronomers were not
explicitly taught computer science and software development,
The documentation of the astropy core package contains despite the fact that a substantial fraction of many astronomers’
narrative descriptions of the package’s functionality, along with workload today is related to software use and development. The
detailed usage notes for functions, classes, and modules. While astropy package leads by example, showing all interested
useful as a reference for more experienced Python users, it is astronomers how modern tools like git version control or CI
not the proper point of entry for other users or learning testing can increase the quality, accessibility, and discoverability
environments. In the near future, we will launch a new resource of astronomical software without overly complicating the
for learning to use both the astropy core package and the development cycle. Within Astropy, all submitted code is
many packages in the broader Astropy ecosystem, under the reviewed by at least one (but typically more than one) member
name Learn Astropy. of the Astropy community. Reviewers provide feedback to
The new Learn Astropy site will present several different contributors, which helps to improve contributors’ software
ways to engage with the Astropy ecosystem: development skills. As a community, Astropy follows an explicit
Documentation: The astropy and affiliated package code of conduct (Cruz et al. 2015) and treats all contributors and
documentation contains the complete description of a users with respect, provides a harassment-free environment, and
package with all requisite details, including usage, depen- encourages and welcomes new contributions from all. Thus,
dencies, and examples. The pages will largely remain as-is, while the Astropy Project provides and develops software and
but will be focused toward more intermediate users and as a tools essential to modern astronomical research, it also helps to
reference resource. prepare the current and next generation of researchers with the
Examples: These are stand-alone code snippets that live in knowledge to adequately use, develop, and contribute to those
the astropy documentation that demonstrate a specific tools within a conscientious and welcoming community.
functionality within a subpackage. The astropy core
package documentation will then gain a new “index of We thank the referee for an insightful report that improved
examples” that links to all of the code or demonstrative the paper. We would like to thank the members of the
examples within any documentation page. community who have contributed to Astropy, who have opened
Tutorials: The Astropy tutorials are step-by-step demonstra- issues and provided feedback, and who have supported the
tions of common tasks that incorporate several packages or project in a number of different ways. We would like to
subpackages. Tutorials are more extended and comprehen- acknowledge Alex Conley and Neil Crighton for maintaining
sive than examples, may contain exercises for the users, and theastropy.cosmology subpackage.
are generally geared towards workshops or teaching. Several The Astropy community is supported by and makes use of a
tutorials already exist125 and are being actively expanded. number of organizations and services outside the traditional
Guides: These are long-form narrative, comprehensive, and academic community. We thank Google for financing and
conceptually focused documents (roughly one book chapter in organizing the Google Summer of Code (GSoC) program, that
length), providing stand-alone introductions to core packages has funded several students per year to work on Astropy related
in addition to the underlying astronomical concepts. These are projects over the summer. These students often turn into long-
less specific and more conceptual than tutorials: for example, term contributors. We also thank NumFOCUS and the Python
“using astropy and ccdproc to reduce imaging data.” Software Foundation for financial support. Within the academic
We encourage any users who wish to see specific material to community, we thank institutions that make it possible for
either contribute or comment on these efforts via the Astropy astronomers and other developers on their staff to contribute
mailing list or astropy/astropy-tutorials GitHub their time to the development of Astropy projects. We
repository.126 acknowledge the support of the Space Telescope Science
Institute, Harvard–Smithsonian Center for Astrophysics, and
the South African Astronomical Observatory.
6. Conclusion The following individuals would like to recognize support for
The astropy package is improving in stability, breadth, and their personal contributions. H.M.G. was supported by the
reliability while the the Astropy project is still significantly National Aeronautics and Space Administration through the
growing. As the astropy core package becomes more mature, Smithsonian Astrophysical Observatory contract SV3-73016 to
several subpackages have reached stability with a rich set of MIT for Support of the Chandra X-Ray Center, which is
features that help astronomers worldwide to perform many daily operated by the Smithsonian Astrophysical Observatory for and
tasks, such as planning observations, analyzing data or on behalf of the National Aeronautics Space Administration
simulation results, and writing publications. The strong emphasis under contract NAS8-03060. J.T.V. was supported by the UW
that the Astropy Project puts on reliability and high coding eScience Institute via grants from the Moore Foundation, the
Sloan Foundation, and the Washington Research Foundation.
125
http://tutorials.astropy.org/ S.M.C. acknowledges the National Research Foundation of
126
https://github.com/astropy/astropy-tutorials South Africa. M.V.B. was supported by NASA’s Planetary

16
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Astronomy Program. T.L.A. was supported by NASA contract Furthermore, the astropy packages would not exist in their
NAS8-03060. Support for E.J.T. was provided by NASA through current form without a number of web services for code
Hubble Fellowship grant No. 51316.01 awarded by the Space hosting, continuous integration, and documentation; in part-
Telescope Science Institute, which is operated by the Association icular, astropy heavily relies on GitHub, Travis CI, Appveyor,
of Universities for Research in Astronomy, Inc., for NASA, CircleCI, and Read the Docs.
under contract NAS 5-26555, as well as a Giacconi Fellowship. Astropy interfaces with the SIMBAD database, operated at
M.B. was supported by the FONDECYT regular project 1170618 CDS, Strasbourg, France. It also makes use of the ERFA library
and the MINEDUC-UA projects codes ANT 1655 and ANT (Tollerud et al. 2017), which in turn derives from the IAU SOFA
1656. D.H. was supported through the SFB 881 “The Milky Way Collection127 developed by the International Astronomical
System” by the German Research Foundation (DFG). W.E.K Union Standards of Fundamental Astronomy (Hohenkerk 2011).
was supported by an ESO Fellowship. C.M. is supported by NSF Software:astropy (Astropy Collaboration et al. 2013),
grant AST-1313484. S.P. was supported by grant AYA2016- numpy (Van der Walt et al. 2011), scipy (Jones et al.
75808-R (FEDER) issued by the Spanish government. J.E.H.T. 2001), matplotlib (Hunter 2007), Cython (Behnel
was supported by the Gemini Observatory, which is operated by et al. 2011), SOFA (Hohenkerk 2011), ERFA (Tollerud
the Association of Universities for Research in Astronomy, Inc., et al. 2017).
on behalf of the international Gemini partnership of Argentina,
Brazil, Canada, Chile, and the United States of America. Y.P.B
Appendix
was supported by the Korea Astronomy and Space Science
List of Affiliated Packages
Institute, under the R&D program supervised by the Ministry of
Science, ICT, and Future Planning. The Appendix comprises Table 1.

Table 1
Registry of Affiliated Packages

Package Name Stable PyPI Name Maintainer Citation

APLpy Yes APLpy Thomas Robitaille and Eli Bressert Robitaille & Bressert (2012)
Astro-SCRAPPY Yes astroscrappy Curtis McCully van Dokkum (2001)
astroML Yes astroML Jake Vanderplas Vanderplas et al. (2012), Ivezić
et al. (2014)
astroplan No astroplan Brett Morris Morris et al. (2018)
astroquery Yes astroquery Adam Ginsburg and Brigitta Sipocz Ginsburg et al. (2017b)
ccdproc Yes ccdproc Steven Crawford, Matt Craig, and Michael Seifert Craig et al. (2015)
cluster-lensing No cluster-lensing Jes Ford Ford (2016)
gala Yes astro-gala Adrian Price-Whelan Price-Whelan (2017)
galpy Yes galpy Jo Bovy Bovy (2015)
gammapy No gammapy Christoph Deil Deil et al. (2017)
ginga Yes ginga Eric Jeschke and Pey-Lian Lim ejeschke et al. (2017)
Glue Yes glueviz Chris Beaumont and Thomas Robitaille Beaumont et al. (2014)
gwcs No gwcs Nadia Dencheva Dencheva et al. (2017)
Halotools Yes halotools Andrew Hearin Hearin et al. (2017)
HENDRICS Yes hendrics Matteo Bachetti Bachetti (2015)
hips No hips Christoph Deil and Thomas Boch hips developers (2018)
imexam No imexam Megan Sosey Sosey (2017)
linetools Yes linetools J. Xavier Prochaska, Nicolas Tejos, and Neil Crighton Prochaska et al. (2017)
marxs Yes marxs Hans Moritz Günther Günther et al. (2017)
naima Yes naima Victor Zabalza Zabalza (2015)
omnifit Yes omnifit Aleksi Suutarinen Suutarinen (2015)
photutils No photutils Larry Bradley and Brigitta Sipocz Bradley et al. (2017)
poliastro No poliastro Juan Luis Cano Rodríguez Rodríguez et al. (2017)
PyDL No pydl Benjamin Alan Weaver Weaver et al. (2017)
pyregion Yes pyregion Jae-Joon Lee and Christoph Deil pyregions developers (2018)
pyspeckit Yes pyspeckit Adam Ginsburg Ginsburg & Mirocha (2011)
python-cpl No python-cpl Ole Streicher Streicher & Weilbacher (2012)
PyVO No pyvo Stefan Becker Graham et al. (2014)
regions No regions Christoph Deil and Johannes King pyregions developers (2018)
reproject Yes reproject Thomas Robitaille Robitaille (2018)
sncosmo Yes sncosmo Kyle Barbary Barbary (2014)
spectral-cube Yes spectral-cube Adam Ginsburg Ginsburg et al. (2017a)
specutils No specutils Nicholas Earl, Adam Ginsburg, Steve Crawford, and Erik Tollerud specutils developers (2018)
spherical_geometry No spherical-geometry Bernie Simon
stingray No stingray Daniela Huppenkothen, Matteo Bachetti, Abigail Stevens, Simone Huppenkothen et al. (2016)
Migliari, and Paul Balm
synphot Yes synphot Pey Lian Lim Lim (2016)

127
http://www.iausofa.org

17
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

ORCID iDs Cruz, K., Hagen, A., Robitaille, T., Tollerud, E., & Villaume, A. 2015, Astropy
Proposal for Enhancement 8: Astropy Community Code of Conduct (APE 8),
A. M. Price-Whelan https://orcid.org/0000-0003- Zenodo, doi:10.5281/zenodo.1043913
0872-7098 Currie, M. J., Berry, D. S., Jenness, T., et al. 2014, in ASP Conf. Ser. 485,
S. M. Crawford https://orcid.org/0000-0002-8969-5229 Astronomical Data Analysis Software and Systems XXIII, ed. N. Manset &
P. Forshay (San Francisco, CA: ASP), 391
A. Ginsburg https://orcid.org/0000-0001-6431-9633 Deil, C., Zanin, R., Lefaucheur, J., et al. 2017, arXiv:1709.01751
J. T. VanderPlas https://orcid.org/0000-0002-9623-3401 Dencheva, N., Sipocz, B., Jones, C., et al. 2017, spacetelescope/gwcs: GWCS
L. D. Bradley https://orcid.org/0000-0002-7908-9284 v0.8.0, Zenodo, doi:10.5281/zenodo.1041790
M. de Val-Borro https://orcid.org/0000-0002-0455-9384 Disney, M. J., & Wallace, P. T. 1982, QJRAS, 23, 485
K. L. Cruz https://orcid.org/0000-0002-1821-0650 Doe, S., Nguyen, D., Stawarz, C., et al. 2007, in ASP Conf. Ser. 376,
Astronomical Data Analysis Software and Systems XVI, ed. R. A. Shaw,
T. P. Robitaille https://orcid.org/0000-0002-8642-1329 F. Hill, & D. J. Bell (San Francisco, CA: ASP), 543
E. J. Tollerud https://orcid.org/0000-0002-9599-310X ejeschke, Lim, P. L., Rajul, et al. 2017, ejeschke/ginga: Ginga v2.6.6, Zenodo,
M. Bachetti https://orcid.org/0000-0002-4576-9337 doi:10.5281/zenodo.1040969
P. Barmby https://orcid.org/0000-0003-2767-0090 Ford, J. 2016, cluster-lensing: v0.1.2, Zenodo, doi:10.5281/zenodo.51370
Ginsburg, A., & Mirocha, J. 2011, PySpecKit: Python Spectroscopic Toolkit,
G. B. Brammer https://orcid.org/0000-0003-2680-005X Astrophysics Source Code Library, ascl:1109.001
L. H. Garrison https://orcid.org/0000-0002-9853-5673 Ginsburg, A., Robitaille, T., Koch, E., et al. 2017a, radio-astro-tools/spectral-
D. Homeier https://orcid.org/0000-0002-8546-9128 cube: Version 0.4.1 release, Zenodo, doi:10.5281/zenodo.1013994
G. Hosseinzadeh https://orcid.org/0000-0002-0832-2974 Ginsburg, A., Sipocz, B., Parikh, M., et al. 2017b, astropy/astroquery: v0.3.6
T. Jenness https://orcid.org/0000-0001-5982-167X with fixed license, Zenodo, doi:10.5281/zenodo.826911
Graham, M., Plante, R., Tody, D., & Fitzpatrick, M. 2014, PyVO: Python access to
S. Kendrew https://orcid.org/0000-0002-7612-0469 the Virtual Observatory, Astrophysics Source Code Library, ascl:1402.004
N. S. Kern https://orcid.org/0000-0002-8211-1892 Greenfield, P. 2013, Astropy Proposal for Enhancement 1: APE Purpose and
C. McCully https://orcid.org/0000-0001-5807-7893 Process (APE 1), Zenodo, doi:10.5281/zenodo.1043886
B. M. Morris https://orcid.org/0000-0003-2528-3409 Günther, H. M., Frost, J., & Theriault-Shay, A. 2017, AJ, 154, 243
Hearin, A. P., Campbell, D., Tollerud, E., et al. 2017, AJ, 154, 190
S. Pascual https://orcid.org/0000-0002-9351-6051 hips developers 2018, hips—Python library to handle HiPS data, https://
A. L. Plunkett https://orcid.org/0000-0002-9912-5705 github.com/hipspy/hips
J. X. Prochaska https://orcid.org/0000-0002-7738-6875 Hohenkerk, C. 2011, SchpJ, 6, 11404
L. P. Singer https://orcid.org/0000-0001-9898-5597 Hunter, J. D. 2007, CS&E, 9, 90
P. Teuben https://orcid.org/0000-0003-1774-3436 Huppenkothen, D., Bachetti, M., Stevens, A. L., Migliari, S., & Balm, P. 2016,
Stingray: Spectral-timing software, Astrophysics Source Code Library,
G. R. Tremblay https://orcid.org/0000-0002-5445-5401 ascl:1608.001
A. de la Vega https://orcid.org/0000-0002-6219-5558 Ivezić, Ž., Connolly, A., Vanderplas, J., & Gray, A. 2014, Statistics, Data
L. L. Watkins https://orcid.org/0000-0002-1343-134X Mining and Machine Learning in Astronomy (Princeton, NJ: Princeton
J. Woillez https://orcid.org/0000-0002-2958-4738 Univ. Press)
Jammalamadaka, S. R., & Sengupta, A. 2001, Topics in Circular Statistics
(Singapore: World Scientific)
Jenness, T., & Berry, D. S. 2013, in ASP Conf. Ser. 475, Astronomical Data
References Analysis Software and Systems XXII, ed. D. N. Friedel (San Francisco,
CA: ASP), 307
Aldcroft, T. 2015, Astropy Proposal for Enhancement 6: Enhanced Character Jenness, T., Bosch, J., Owen, R., et al. 2016, Proc. SPIE, 9913, 99130G
Separated Values table format (APE 6), Zenodo, doi:10.5281/zenodo. Jones, E., Oliphant, T., Peterson, P., et al. 2001, SciPy: Open source scientific
1043901 tools for Python, http://www.scipy.org/
Astropy Collaboration, Robitaille, T. P., Tollerud, E. J., et al. 2013, A&A, Knutsson, H., & Westin, C. F. 1993, in Proc. IEEE Conf. on Computer
558, A33 Visionand Pattern Recognition (New York: IEEE), 515
Bachetti, M. 2015, MaLTPyNT: Quick look timing analysis for NuSTAR data, Lim, P. L., et al. 2016, synphot Userʼs Guide (Baltimore, MD: STScI), https://
Astrophysics Source Code Library, ascl:1502.021 synphot.readthedocs.io/en/latest/
Banse, K., Ponz, D., Ounnas, C., Grosbol, P., & Warmels, R. 1988, in Lomb, N. R. 1976, Ap&SS, 39, 447
Instrumentation for Ground-Based Optical Astronomy, ed. L. B. Robinson Lupton, R., Blanton, M. R., Fekete, G., et al. 2004, PASP, 116, 133
(New York: Springer-Verlag), 431 Mamajek, E. E., Prsa, A., Torres, G., et al. 2015, arXiv:1510.07674
Barbary, K. 2014, sncosmo v0.4.2, Zenodo, doi:10.5281/zenodo.11938 McKinney, W. 2010, in Proc. 9th Python in Science Conf., ed.
Barrett, P. E., & Bridgman, W. T. 1999, in ASP Conf. Ser. 172, Astronomical Data S. vander Walt & J. Millman, 51
Analysis Software and Systems VIII, ed. D. M. Mehringer, R. L. Plante, & Mohr, P. J., Newell, D. B., & Taylor, B. N. 2016, RvMP, 88, 035009
D. A. Roberts (San Francisco, CA: ASP), 483 Morris, B. M., Tollerud, E., Sipőcz, B., et al. 2018, AJ, 155, 128
Barron, E. G., Kaplan, G. H., Bangert, J., et al. 2011, BAAS, 43, 344.14 Muna, D., Alexander, M., Allen, A., et al. 2016, arXiv:1610.03159
Beaumont, C., Robitaille, T., Borkin, M., & Goodman, A. 2014, glueviz v0.4: Palmer, D. M. 2009, ApJ, 695, 496
multidimensional data exploration, Zenodo, doi:10.5281/zenodo.13866 Pence, W. D., Chiappetti, L., Page, C. G., Shaw, R. A., & Stobie, E. 2010,
Beerer, I. M., Koenig, X. P., Hora, J. L., et al. 2010, ApJ, 720, 679 A&A, 524, A42
Beers, T. C., Flynn, K., & Gebhardt, K. 1990, AJ, 100, 32 Planck Collaboration, Ade, P. A. R., Aghanim, N., et al. 2016, A&A, 594, A13
Behnel, S., Bradshaw, R., Citro, C., et al. 2011, CSE, 13, 31 Press, W. H., & Rybicki, G. B. 1989, ApJ, 338, 277
Berry, D. S., Warren-Smith, R. F., & Jenness, T. 2016, A&C, 15, 33 Price-Whelan, A., Crawford, S., Sipocz, B., et al. 2018, astropy/astropy-v2.0-
Bovy, J. 2015, ApJS, 216, 29 paper: final draft, Zenodo, doi:10.5281/zenodo.1211397
Bradley, L., Sipocz, B., Robitaille, T., et al. 2017, astropy/photutils: v0.4, Price-Whelan, A. M. 2017, JOSS, 2, doi:10.21105/joss.00388
Zenodo, doi:10.5281/zenodo.1039309 Prochaska, J. X., Tejos, N., Crighton, N., et al. 2017, linetools/linetools: Third
Bretthorst, G. L. 2003, in Statistical Challenges in Astronomy. Third Statistical Minor Release, Zenodo, doi:10.5281/zenodo.1036773
Challenges in Modern Astronomy (SCMA III) Conf., ed. E. D. Feigelson & pyregions developers 2018, regions—ds9 region parser for python, https://
G. J. Babu (New York: Springer), 309 github.com/astropy/pyregion
Craig, M. W., Crawford, S. M., Deil, C., et al. 2015, ccdproc: CCD data Rhodes, B. C. 2011, PyEphem: Astronomical Ephemeris for Python,
reduction software, Astrophysics Source Code Library, ascl:1510.007 Astrophysics Source Code Library, ascl:1112.014
Crawford, S., Earl, N., Ginsburg, A., & Tollerud, E. 2017, Vision for Astropy Robitaille, T. 2017, Astropy Proposal for Enhancement: Roadmap for Python
Spectroscopic Tools (APE 13), Zenodo, doi:10.5281/zenodo.1117943 3-only support (APE 10), Zenodo, doi:10.5281/zenodo.1038587

18
The Astronomical Journal, 156:123 (19pp), 2018 September Price-Whelan et al.

Robitaille, T. 2018, reproject: astronomical image reprojection in Python, Tollerud, E. 2013, Astropy Proposal for Enhancement 2: Astropy Release
Zenodo, doi:10.5281/zenodo.1162674 Cycle and Version Numbering (APE 2), Zenodo, doi:10.5281/zenodo.
Robitaille, T., & Bressert, E. 2012, APLpy: Astronomical Plotting Library in 1043888
Python, Astrophysics Source Code Library, ascl:1208.017 Tollerud, E., Pascual, S., Nair, P., et al. 2017, liberfa/erfa: v1.4.0, Zenodo,
Rodríguez, J. L. C., Hidalgo, A., Márquez, A. L., et al. 2017, poliastro/poliastro: doi:10.5281/zenodo.1021149
poliastro 0.8.0 (OSCW edition), Zenodo, doi:10.5281/zenodo.1058988 Tollerud, E., Price-Whelan, A., Aldcroft, T., & Robitaille, T. 2014, Astropy
Scargle, J. D. 1982, ApJ, 263, 835 Proposal for Enhancement 5: Coordinates Subpackage Plan (APE 5),
Scargle, J. D., Norris, J. P., Jackson, B., & Chiang, J. 2013, ApJ, 764, 167 Zenodo, doi:10.5281/zenodo.1043897
Seabold, S., & Perktold, J. 2010, in 9th Python in Science Conf., ed. S. van der Turk, M. J., Smith, B. D., Oishi, J. S., et al. 2011, ApJS, 192, 9
Walt & J. Millman Van der Walt, S., Colbert, S. C., & Varoquaux, G. 2011, CSE, 13, 22
Sosey, M. 2017, imexam version 0.8.0 release, Zenodo, doi:10.5281/zenodo. van Dokkum, P. G. 2001, PASP, 113, 1420
1042809 VanderPlas, J. 2018, ApJS, arXiv:1703.09824
specutils developers 2018, specutils—Affiliated package for 1D spectral VanderPlas, J., Connolly, A., Ivezić, Ž., & Gray, A. 2012, in Conf. on
operations, https://github.com/astropy/specutils Intelligent Data Understanding (CIDU), ed. K. Das et al. (New York:
Streicher, O., & Weilbacher, P. M. 2012, in ASP Conf. Ser. 461, Astronomical IEEE), 47
Data Analysis Software and Systems XXI, ed. P. Ballester, D. Egret, & VanderPlas, J. T., & Ivezic, Z. 2015, arXiv:1502.01344
N. P. F. Lorente (San Francisco, CA: ASP), 853 Wallace, P. T. 1994, in ASP Conf. Ser. 61, Astronomical Data Analysis
Suutarinen, A. 2015, omnifit: v0.2.1, Zenodo, doi:10.5281/zenodo.35536 Software and Systems III, ed. D. R. Crabtree, R. J. Hanisch, & J. Barnes
Terlouw, J. P., & Vogelaar, M. G. R. 2015, Kapteyn Package, version 2.3 (San Francisco, CA: ASP), 481
(Groningen: Kapteyn Astronomical Institute) Weaver, B. A., Barbary, K., Bradley, K., et al. 2017, weaverba137/pydl: PyDL
Tody, D. 1993, in ASP Conf. Ser. 52, Astronomical Data Analysis Software v0.6.0, Zenodo, doi:10.5281/zenodo.1095151
and Systems II, ed. R. J. Hanisch, R. J. V. Brissenden, & J. Barnes (San Zabalza, V. 2015, Proc. ICRC, 922
Francisco, CA: ASP), 173 Zechmeister, M., & Kürster, M. 2009, A&A, 496, 577

19