The Astropy Project: Building an Open-science Project and Status of the v2.0 Core Package^*

From its inception, Astropy has required coordination to ensure the project as a whole and its coding efforts are consistent and reasonably efficient. While many Python projects adopt a "Benevolent Dictator For Life" (BDFL) model, Astropy has instead opted for a coordination committee. This is partly due to the nature of the project as a large-scale collaboration between many contributors with many interests, and partly due to the sheer amount of work that needs to get done. For the latter reason, the project has expanded the committee from three to four members starting in 2016.

For resolving disagreements about the astropy core package or other Astropy-managed code, the coordination committee primarily acts to work toward consensus, or when consensus is difficult to achieve, generally acts as a "tie-breaker." The committee also oversees affiliated package applications to ensure that they are in keeping with Astropy's vision and philosophy,¹⁰³ as well as the associated procedures. Additionally, the committee oversees the assignment of roles (primarily driven by already-existing contributions), and increasingly has acted as the "face" of the Project, providing contact with organizations like NumFOCUS (the body that holds any potential funding in trust for Astropy) and the American Astronomical Society (AAS).

Code is contributed to the astropy core package or modified through "pull requests" (via GitHub¹⁰⁴ ) that often contain several git commits. Pull requests may fix bugs, implement new features, or improve or modify the infrastructure that supports the development and maintenance of the package. Individual pull requests are generally limited to a single conceptual addition or modification, to make code review tractable. Pull requests that modify or add code to a specific subpackage must be reviewed and approved by one of the subpackage maintainers before they are merged into the core codebase. Bugs and feature requests are reported via the GitHub issue tracker and labeled with a set of possible labels that help classify and organize the issues. The development workflow is detailed in the astropy documentation.¹⁰⁵

As of version 2.0, astropy contains 212,244 lines of code¹⁰⁶ contributed by 232 unique contributors over 19,270 git commits. Figure 1, left, shows the distribution of total number of commits per contributor as of early 2018. The relative flatness of this distribution (as demonstrated by its log-log slope of −0.5) shows that the astropy core package has been developed by a broad contributor base. A leading group of six developers have each added over 1000 commits to the repository, and ∼20 more core contributors have contributed at least 100 commits. However, the distribution of contribution level (number of commits) continues from 100 down to a single commit. In this sense, the development of the core package has been a true community effort and is not dominated by a single individual. It is also important to note that the number of commits is only a rough metric of contribution, as any single commit could be a critical fix in the package or merely a fix for a typographical error. Figure 1, middle, shows the number of commits as a function of time since the genesis of the astropy core package. The package is still healthy: new commits are and have been contributed at a steady rate throughout its existence. Figure 1, right, shows that, ≈20–25 people contribute to the core package each month. While we would like for this number to grow, this demonstrates that the core package is still being developed and maintained by a substantial group of contributors.

Zoom In Zoom Out Reset image size

The Astropy project has a formal mechanism to propose significant changes to the core package (e.g., re-writing the coordinates subpackage; Tollerud et al. 2014), to plan out major new features (e.g., a new file format; Aldcroft 2015), or to institute new organization-wide policies (e.g., adopting a code of conduct; Cruz et al. 2015). This mechanism is called "Astropy Proposal for Enhancement" (APE) and is modeled after the "Python Enhancement Proposals" (PEP) that guide the development of the Python programming language. In an APE, one or more authors describe in detail the proposed changes or additions, including a rationale for the changes, how these changes will be implemented, and in the case of code, what the interface will be (Greenfield 2013). The APEs are discussed and refined by the community before much work is invested into a detailed implementation; anyone is welcome to contribute to these discussions during the open consideration period. APEs are proposed via pull requests on a dedicated GitHub repository¹⁰⁷ ; therefore, anyone can read the proposed APEs and leave in-line comments. When a community consensus emerges, the APEs are accepted and become the basis for future work. In cases where consensus cannot be reached, the Astropy coordination committee may decide to close the discussion and make an executive decision based on the community input on the APE in question.

A major part of the Astropy Project is the concept of "Affiliated Packages." An affiliated package is an astronomy-related Python package that is not part of the astropy core package, but has requested to be included as part of the Astropy Project's community. These packages support the goals and vision of Astropy of improving code re-use, interoperability, and embracing good coding practices such as testing and thorough documentation.

Affiliated packages contain functionality that is more specialized, have license incompatibilities, or have external dependencies (e.g., GUI libraries) that make these packages more suitable to be separate from the astropy core package. Affiliated packages may also be used to develop substantial new functionality that will eventually be incorporated into the astropy core package (e.g., astropy.visualization.wcsaxes). New functionality benefits from having a rapid development and release cycle that is not tied to that of the astropy core (Section 2.5). These projects may also have less stringent requirements for style, testing, or development as compared to the core package.

Affiliated packages are listed on the main Astropy website and advertised to the community through Astropy mailing lists; a list of current affiliated packages is included in Table 1. Becoming an affiliated package is a good way for new and existing packages to gain exposure while promoting Astropy's high standard for code and documentation quality. This process of listing and promoting affiliated packages is one way in which the Astropy Project tries to increase code re-use in the astronomical community.

Packages can become affiliated with Astropy by applying for this status on a public mailing list. The coordination committee (Section 2.1) reviews such requests and issues recommendations for the improvement of a package, where applicable.

The astropy package has a regular release schedule consisting of new significant releases every six months, with bugfix releases as needed (Tollerud 2013). The major releases contain new features or any significant changes, whereas the bugfix releases only contain fixes to code or documentation but no new features. Some versions are additionally designated as "Long-term support" (LTS) releases, which continue to receive bug fixes for two years following the release with no changes to the API. The LTS versions are ideal for pipelines and other applications in which API stability is essential. The latest LTS release (version 2.0) is also the last one that supports Python 2; it will receive bug fixes until the end of 2019 (Robitaille 2017).

The version numbering of the astropy core package reflects this release scheme: the core package version number uses the form x.y.z, where "x" is advanced for LTS releases, "y" for non-LTS feature releases, and "z" for bugfix releases. This is similar to Semantic Versioning.¹⁰⁸

The released versions of the astropy core package are available from several of the Python distributions for scientific computing (e.g., Anaconda) and from the Python Package Index (PyPI).¹⁰⁹ Effort has been made to make 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.

The Astropy Project, as of the version 2.0 release, does not receive any direct financial support for the development of astropy. Development of the software, all supporting materials, and community support are provided by individuals who work on the Astropy Project in their own personal time, by individuals or groups contributing to Astropy as part of a research project, or contributions from institutions that allocate people to work on Astropy. A list of organizations that have contributed to Astropy in this manner can be found in the Acknowledgments.

Different funding models have been proposed for support of Astropy (e.g., Muna et al. 2016), but a long-term plan for sustainability has not yet been established. The Astropy Project has the ability to accept financial contributions from institutions or individuals through the NumFOCUS¹¹⁰ organization. NumFOCUS has, to date, covered the direct costs incurred by the Astropy Project.

The Astropy Project is built on a philosophy of building from the existing Python scientific ecosystem wherever possible. Many of the enabling technologies like numpy, scipy, matplotlib, or cython, are necessary as the core underpinnings of Astropy packages. Often, this means using these packages as "building blocks" (e.g., the ubiquitous use of numpy arrays throughout astropy). In other cases, this means wrappers around more general algorithms that make them more convenient for astronomy use cases (e.g., the model-fitting in the astropy.modeling subpackage discussed in Section 3.7). Sometimes these simple wrappers evolve into more complex implementations that address astronomically relevant use cases the general tool does not support (e.g., astropy.convolution, see Section 3.8). As 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 often ambiguous. Some of the examples above only evolved after significant debate in the community over whether these algorithms were sufficient. Other times, even apparently general functionality did not exist in the wider ecosystem that met the Astropy community's needs, and hence the functionality had to be developed wholly from the developer resources available in the community (e.g., astropy.units, or 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 well as the testing and documentation architecture. Functionality is only "extracted" from Astropy to other packages after careful consideration that includes considering the impact on the maintenance and support of Astropy.

The astropy.units subpackage adds support for representing units and numbers with associated units—"quantities"—in code. Historically, quantities in code have often been represented simply as numbers, with units implied or noted via comments in the code because of considerations about speed: having units associated with numbers inherently adds overhead to numerical operations. In astropy.units, Quantity objects extend numpy array objects and have been designed with speed in mind.

As of astropy version 2.0, units and quantities, prevalent in most of its subpackages, have become a key concept for using the package as a whole. Units are intimately entwined in the definition of astronomical coordinates; thus, nearly all functionality in the astropy.coordinates subpackage (see Section 3.3) depends on them. Most astropy subpackages have been made compatible with Quantity objects, although they are not always required.

The motivation and key concepts behind this subpackage were described in detail in the previous paper (Astropy Collaboration et al. 2013). Therefore, we primarily highlight new features and improvements here.

3.1.1. Interaction with numpy Arrays

3.1.2. Logarithmic Units and Magnitudes

3.1.3. Defining Functions that Require Quantities

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 Astropy Collaboration et al. (2013). In version 2.0, the built-in constants have been organized into modules for specific versions of the constant values. For example, physical constants have codata2014 (Mohr et al. 2016) and codata2010 versions. Astronomical constants are organized into iau2015 and iau2012 modules to indicate their sources (resolutions from the International Astronomical Union, IAU). The codata2014 and iau2015 versions are combined into the default constant value version: astropyconst20. For compatibility with astropy version 1.3, astropyconst13 is available and provides access to the adopted versions of the constants from earlier versions of astropy. To use previous versions of the constants as units (e.g., solar masses), the values have to be imported directly; with version 2.0, astropy.units uses the astropyconst20 versions.

Astronomers using astropy.constants should take particular note of the constants provided for Earth, Jupiter, and the Sun. Following IAU 2015 Resolution B3 (Mamajek et al. 2015), nominal values are now given for mass parameters and radii. The nominal values will not change even as "current best estimates" are updated.

The astropy.coordinates subpackage is designed to support representing and transforming celestial coordinates and—new in version 2.0—velocities. The framework heavily relies on the astropy.units subpackage, and most inputs to objects in this subpackage are expected to be Quantity objects. Some of the machinery also relies on the Essential Routines of Fundamental Astronomy (ERFA) C library for some of the critical underlying transformation machinery (Tollerud et al. 2017), which is based on the Standards Of Fundamental Astronomy (SOFA) effort (Hohenkerk 2011).

A key concept behind the design of this subpackage is that coordinate representations and reference systems/frames are independent of one another. For example, a set of coordinates in the International Celestial Reference System (ICRS) reference frame could be represented as spherical (right ascension, declination, and distance from solar system barycenter) or Cartesian coordinates (x, y, z with the origin at barycenter). They can therefore change representations independent of being transformed to other reference frames (e.g., the Galactic coordinate frame).

The classes that handle coordinate representations (the Representation classes) act like three-dimensional vectors and thus support vector arithmetic. The classes that represent reference systems and frames (the Frame classes) internally use Representation objects to store the coordinate data—that is, the Frame classes accept coordinate data, either as a specified Representation object, or using short-hand keyword arguments to specify the components of the coordinates. These preferred representation and short-hand component names differ between various astronomical reference systems. For example, in the ICRS frame, the spherical angles are right ascension (ra) and declination (dec), whereas in the Galactic frame, the spherical angles are Galactic longitude (l) and latitude (b). Each Frame class defines its own component names and preferred Representation class. The frame-specific component names map to corresponding components on the underlying Representation object that internally stores the coordinate data. For most frames, the preferred representation is spherical, although this is determined primarily by their common use in the astronomical community.

Many of the Frame classes also have attributes specific to the corresponding reference system that allow the user to specify the frame. For example, the Fifth Fundamental Catalogue (FK5) reference system requires specifying an equinox to determine the reference frame. If required, these additional frame attributes must be specified, along with the coordinate data, when a Frame object is created. Figure 2 shows the network of possible reference frame transformations as currently implemented in astropy.coordinates. Custom user-implemented Frame classes that define transformations to any reference frame in this graph can then be transformed to any of the other connected frames.

Zoom In Zoom Out Reset image size

The typical user does not usually have to interact directly with the Frame or Representation classes. Instead, astropy.coordinates provides a high-level interface to representing astronomical coordinates through the SkyCoord class, which was designed to provide a single class that accepts a wide range of possible inputs. It supports coordinate data in any coordinate frame in any representation by internally using the Frame and Representation classes.

In what follows, we briefly highlight key new features in astropy.coordinates.

3.3.1. Local Earth Coordinate Frames

3.3.2. Proper Motion and Velocity Transformations

3.3.3. Solar System Ephemerides

3.3.4. Accuracy of Coordinate Transformations

In order to check the accuracy of the coordinate transformations in astropy.coordinates, we have created a set of benchmarks that we use to compare transformations between a set of coordinate frames for a number of packages.¹¹⁴ Because no package can be guaranteed to implement all transformations to arbitrary precision and some transformations are sometimes subject to interpretation of standards (particularly in the case of 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 Astropy Project because they allow all of the tools to be compared to all other tools. The tools included in the benchmark at the moment include the astropy core package, Kapteyn (Terlouw & Vogelaar 2015), NOVAS (Barron et al. 2011), PALpy (Jenness & Berry 2013), PyAST (a wrapper for AST, described in Berry et al. 2016), PyTPM,¹¹⁵ PyEphem (Rhodes 2011), and pySLALIB (a Python wrapper for SLALIB, described in Wallace 1994).

The benchmarks are meant to evolve over time and include an increasing variety of cases. At the moment, the benchmarks are set up as follows—we have generated a standard set of 1000 pairs of random longitudes/latitudes that we use in all benchmarks. Each benchmark is then defined using an input and output coordinate frame, using all combinations of FK4, FK5, Galactic, ICRS, and Ecliptic frames. For now, we set the epoch of observation to J2000. We also set the frame to J2000 (for FK5 and Ecliptic) and B1950 (for FK4). In the future, we plan to include a larger variety of epochs and equinoxes, as well as tests of conversion to/from Altitude/Azimuth. For each benchmark, we convert the 1000 longitudes/latitudes from the input/output frame with all tools and quantify the comparison by looking at the median, mean, maximum, and standard deviation of the absolute separation of the output coordinates from each pair of tools.

Figure 3 visualizes the relative accuracy of the conversion from FK4 to Galactic coordinates for all pairs of tools that implement this transformation. In this figure, the color of the cell indicates the maximum difference (in arcseconds) between the two tools over the 1000 longitude-latitude pairs tested. This figure shows, for example, that astropy, Kapteyn, and PyTPM agree with sub-milliarcsecond differences (light colors, small differences), while PALpy, pySLALIB, and PyAST also agree among themselves. However, there is an offset of around 02 between the two groups. Finally, PyEphem disagrees with all other packages by 04–08 (darker colors, large differences). These values are only meant to be illustrative and will change over time as the benchmarks are refined and the packages updated.

Zoom In Zoom Out Reset image size

The astropy.time subpackage focuses on supporting timescales (e.g., UTC, TAI, UT1) and time formats (e.g., Julian date, modified Julian date) that are commonly used in astronomy. This functionality is needed, for example, to calculate barycentric corrections or sidereal times. astropy.time is currently built on the ERFA (Tollerud et al. 2017) C library, which replicates the Standards of Fundamental Astronomy (SOFA; Hohenkerk 2011) but is licensed under a three-clause BSD license. The package was described in detail in Astropy Collaboration et al. (2013) and has remained stable for the last several versions of astropy. Thus, in what follows, we only highlight significant changes or new features since the previous Astropy paper.

3.4.1. Barycentric and Heliocentric Corrections

3.5.1. nddata

3.5.2. Tables

The astropy.io subpackages provide support for reading and writing data to a variety of ASCII and binary file formats, such as a wide range of ASCII data table formats, FITS, HDF5, and VOTable. It also provides a unified interface for reading and writing data with these different formats using the astropy.table subpackage. For many common cases, this simplifies the process of file input and output (I/O) and reduces the need to master the separate details of all the I/O packages within astropy. The file interface allows transparent compression of the gzip, bzip2, and lzma (.xz) formats; the latter two require the Python installation to have been compiled with support the respective libraries.

3.6.1. ASCII

3.6.2. FITS

3.6.3. HDF5

The astropy.modeling subpackage provides a framework for representing analytical models and performing model evaluation and parameter fitting. The main motivation for this functionality was to create a framework that allows arbitrary combination of models to support the Generalized World Coordinate System (GWCS) package.¹¹⁶ The current FITS WCS specification lacks the flexibility to represent arbitrary distortions and does not meet the needs of many types of current instrumentation. The fact that the astropy modeling framework now supports propagating units also makes it a useful tool for representing and fitting astrophysical models within data analysis tools.

Models and fitters are independent of each other: a model can be fit with different fitters and new fitters can be added without changing existing models. The framework is designed to be flexible and easily extensible. The goal is to have a rich set of models, but also facilitate creating new ones, if necessary.

3.7.1. Single Model Definition and Evaluation

3.7.2. Model Sets

3.7.3. Compound Models

3.7.4. Fitting Models to Data

3.7.5. Creating New Models

3.7.6. Unit Support

The astropy.convolution subpackage implements normalized convolution (e.g., Knutsson & Westin 1993), an image reconstruction technique in which missing data are ignored during the convolution and replaced with values interpolated using the kernel. An example is given in Figure 4. In astropy versions ≤1.3, the direct convolution and Fast Fourier Transform (FFT) convolution approaches were inconsistent, with only the latter implementing normalized convolution. As of version 2.0, the two methods now agree and include a suite of consistency checks.

Zoom In Zoom Out Reset image size

The astropy.visualization subpackage provides functionality that can be helpful when visualizing data. This includes a framework (previously the standalone astropy.visualization.wcsaxes package) for plotting astronomical images with coordinates via matplotlib, functionality related to image normalization (including both scaling and stretching), smart histogram plotting, red-green-blue (RGB) color image creation from separate images, and custom plotting styles for matplotlib.

3.9.1. Image Stretching and Normalization

Using astropy.visualization provides a framework for transforming values in images (and more generally, any arrays), typically for the purpose of visualization. The two main types of transformations are normalization and stretching of image values.

Normalization transforms the image values to the range [0, 1] using lower and upper limits (v_min, v_max),

$$\begin{eqnarray}&&y=\displaystyle \frac{x-{v}_{\min }}{{v}_{\max }-{v}_{\min }},\end{eqnarray} \tag{ 1 }$$

where x represents the values in the original image.

Stretching transforms the image values in the range [0, 1] again to the range [0, 1], using a linear or nonlinear function:

$$\begin{eqnarray}&&z=f(y).\end{eqnarray} \tag{ 2 }$$

Several classes are provided for automatically determining intervals (e.g., using image percentiles) and for normalizing values in this interval to the [0, 1] range.

Using matplotlib allows a custom normalization and stretch to be used when displaying data by passing in a normalization object. The astropy.visualization package also provides a normalization class that wraps the interval and stretches objects into a normalization object that matplotlib understands.

3.9.2. Plotting Image Data with World Coordinates

Astronomers dealing with observational imaging commonly need to make figures with images that include the correct coordinates and optionally display a coordinate grid. The challenge, however, is that the conceptual coordinate axes (such as longitude/latitude) need not be lined up with the pixel axes of the image. The astropy.visualization.wcsaxes subpackage implements a generalized way of making figures from an image array and a WCS object that provides the transformation between pixel and world coordinates.

World coordinates can be, for example, right ascension and declination, but can also include, for example, velocity, wavelength, frequency, or time. The main features from this subpackage include the ability to control which axes to show which coordinate on (e.g., showing longitude ticks on the top and bottom axes and latitude on the left and right axes), controlling the spacing of the ticks either by specifying the positions to use or providing a tick spacing or an average number of ticks that should be present on each axis, setting the format for the tick labels to ones commonly used by 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 more than two dimensions and slice on-the-fly. Last but not least, it is also able to define non-rectangular frames such as, for example, Aitoff projections.

This subpackage differs from APLpy (Robitaille & Bressert 2012), in that the latter focuses on providing a very high-level interface to plotting that requires very few lines of code to get a good result, whereas astropy.visualization.wcsaxes defines an interface that is much closer to that of matplotlib (Hunter 2007). This enables significantly more advanced visualizations.

An example of a visualization made with astropy.visualization.wcsaxes is shown in Figure 5. This example illustrates the ability to overlay multiple coordinate systems and customize which ticks/labels are shown on which axes around the image. This also uses the image stretching functionality from Section 3.9.1 to show the image in a square-root stretch (automatically updating the tick positions in the colorbar).

Zoom In Zoom Out Reset image size

3.9.3. Choosing Histogram Bins

3.9.4. Creating Color RGB Images

Lupton et al. (2004) describe an "optimal" algorithm for producing RGB composite images from three separate high-dynamic range arrays. The astropy.visualization subpackage provides a convenience function to create such a color image. It also includes an associated set of classes to provide alternate scalings. This functionality was contributed by developers from the Large Synoptic Survey Telescope (LSST) and serves as an example of a contribution to Astropy from a more traditional engineering organization (Jenness et al. 2016).

The Sloan Digital Sky Survey (SDSS) SkyServer color images were made using a variation on this technique. As an example, in Figure 6, we show an RGB color image of the Hickson 88 group, centered near NGC 6977.¹¹⁸ This image was generated from SDSS images using the astropy.visualization tools.

Zoom In Zoom Out Reset image size

The astropy.cosmology subpackage contains classes for representing different cosmologies and functions for calculating commonly used quantities such as look-back time and distance. The subpackage was described in detail in Astropy Collaboration et al. (2013). The default cosmology in astropy version 2.0 is given by the values in Planck Collaboration et al. (2016).

The astropy.stats package provides statistical tools that are useful for astronomy and are either not found in or extend the available functionality of other Python statistics packages, such as scipy (Jones et al. 2001) or statsmodels (Seabold & Perktold 2010). The astropy.stats package also contains a range of functionality used by many different disciplines in astronomy. It is not a complete set of statistical tools, but rather a still growing collection of useful features.

3.11.1. Robust Statistical Estimators

3.11.2. Circular Statistics

3.11.3. Lomb–Scargle Periodograms

3.11.4. Bayesian Blocks and Histogram Binning

The astropy.stats package also includes an implementation of Bayesian Blocks (Scargle et al. 2013), an algorithm for analysis of breakpoints in nonperiodic astronomical time-series. One interesting application of Bayesian Blocks is its use in determining optimal histogram binnings, particularly binnings with unequal bin sizes. This code was adapted, with several improvements, from the astroML package (VanderPlas et al. 2012). An example of a histogram fit using the Bayesian Blocks algorithm is shown in the right panel of Figure 7.

Zoom In Zoom Out Reset image size

Astropy provides a package template—as a separate GitHub repository, astropy/package-template¹¹⁹ —that aims to simplify setting up packaging, testing, and documentation builds for developers of affiliated packages or astropy-dependent packages. Any Python package can make use of this ready-to-go package layout, setup, installation, and Sphinx documentation build infrastructure that was originally developed for the astropy core package and affiliated packages maintained by the Astropy Project. The package template also provides a testing framework, template configurations for continuous integration services, and Cython build support.

Astropy also provides a set of scripts for setting up and configuring continuous integration (CI) services as a GitHub repository, astropy/ci-helpers.¹²⁰ These tools aim to enable package maintainers to control their testing setup and installation process for various CI services through a set of environment variables. While the current development is mostly driven by the needs of the Astropy ecosystem, the actual usage of this package is extremely widespread.¹²¹ The current tools support configuration for Travis CI¹²² and Appveyor CI.¹²³

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 documentation using plain text files that follow a markup language called reStructuredText (RST). These files are then transformed into HTML, PDF, or LATEX documents during the documentation build process. For the Astropy Project, we have developed several Sphinx extensions that facilitate automatically generating API documentation for large projects, like the astropy core package. The main extension we have developed is sphinx-automodapi,¹²⁴ which provides a convenient single RST command to generate a set of documentation pages, listing all of the available classes, functions, and attributes in a given Python module.

One of the most significant changes coming in this next major release will be removing the support for Python 2 (Robitaille 2017): future versions of astropy will only support Python 3.5 or higher. Removing Python 2 support will allow the use of new features exclusive to Python 3, simplify the code base, and reduce the testing overhead for the package. Version 3.0 was released in February 2018.

In the next major release after version 3.0, scheduled for mid-2018, the focus will be on algorithm optimization and documentation improvement. To prepare for this release, we are subjecting the core package to testing, evaluation, and performance monitoring. As a result, less new functionality may be introduced, as a trade-off for better performance.

Beyond the core code, the Astropy Project is also further developing the Astropy-managed affiliated packages. While these may not be integrated into the astropy core package, these projects provide code that is useful to the astronomical community and meet the testing and documentation standards of Astropy. Some of these new efforts include an initiative to develop tools for spectroscopy (Crawford et al. 2017, specutils, specreduc, specviz), integration of LSST software, and support for HEALPIX projection.

The documentation of the astropy core package contains narrative descriptions of the package's functionality, along with detailed usage notes for functions, classes, and modules. While useful as a reference for more experienced Python users, it is not the proper point of entry for other users or learning environments. In the near future, we will launch a new resource for learning to use both the astropy core package and the many packages in the broader Astropy ecosystem, under the name Learn Astropy.

The new Learn Astropy site will present several different ways to engage with the Astropy ecosystem:

• Documentation: The astropy and affiliated package documentation contains the complete description of a package with all requisite details, including usage, dependencies, and examples. The pages will largely remain as-is, but will be focused toward more intermediate users and as a reference resource.
• Examples: These are stand-alone code snippets that live in the astropy documentation that demonstrate a specific functionality within a subpackage. The astropy core package documentation will then gain a new "index of examples" that links to all of the code or demonstrative examples within any documentation page.
• Tutorials: The Astropy tutorials are step-by-step demonstrations of common tasks that incorporate several packages or subpackages. Tutorials are more extended and comprehensive than examples, may contain exercises for the users, and are generally geared towards workshops or teaching. Several tutorials already exist¹²⁵ and are being actively expanded.
• Guides: These are long-form narrative, comprehensive, and conceptually focused documents (roughly one book chapter in length), providing stand-alone introductions to core packages in addition to the underlying astronomical concepts. These are less specific and more conceptual than tutorials: for example, "using astropy and ccdproc to reduce imaging data."

We encourage any users who wish to see specific material to either contribute or comment on these efforts via the Astropy mailing list or astropy/astropy-tutorials GitHub repository.¹²⁶