已知问题#
而大多数错误和问题都是使用 astropy issue tracker ，本文档列出的问题太难修复，可能需要用户进行一些干预才能解决，或者是由其他项目或包中的错误引起的问题。
本页中列出的问题分为两类：第一类是实际算法和接口中已知的问题和缺点，目前还没有修复或解决方法，用户在编写使用 astropy . 其中一些问题仍然是特定于平台的，而其他问题则是非常普遍的。第二类是在配置、构建或安装时出现的常见问题 astropy . 这还包括测试套件可以根据运行它的上下文/平台报告误报的情况。
已知缺陷#
一些操作会使数量失去单位#
数量的子类来自 numpy %s ndarray 虽然我们已经确保了 numpy 函数可以很好地与它们一起工作，但它们并不总是在 scipy 或其他使用 numpy 在内部，但忽略子类。此外，在中国的一些地方， numpy 就其本身而言，我们无法控制行为。例如，在使用数量设置数组切片时必须小心：
>>> import astropy.units as u
>>> import numpy as np
>>> a = np.ones(4)
>>> a[2:3] = 2*u.kg
>>> a
array([1., 1., 2., 1.])
>>> a = np.ones(4)
>>> a[2:3] = 1*u.cm/u.m
>>> a
array([1., 1., 1., 1.])
设置单个数组项或使用数量列表：
>>> a = np.ones(4)
>>> a[2] = 1*u.cm/u.m
>>> a
array([1. , 1. , 0.01, 1. ])
>>> a = np.ones(4)
>>> a[2:3] = [1*u.cm/u.m]
>>> a
array([1. , 1. , 0.01, 1. ])
如果单位不取消，两者都会抛出异常，例如：
>>> a = np.ones(4)
>>> a[2] = 1*u.cm
Traceback (most recent call last):
...
TypeError: only dimensionless scalar quantities can be converted to Python scalars
乘以一个 pandas.Series vbl.用一种. Unit 不会产生 Quantity#
数量可能与某些操作有关 Series 但这一行为并未经过测试。例如，将一个 Series 具有单元的实例将 not 返回一个 Quantity 。它将返回一个 Series 不带任何单位的对象：
>>> import pandas as pd
>>> import astropy.units as u
>>> a = pd.Series([1., 2., 3.])
>>> a * u.m
0 1.0
1 2.0
2 3.0
dtype: float64
若要避免这种情况，最好将 Quantity 直接：
>>> u.Quantity(a, u.m)
<Quantity [1., 2., 3.] m>
请注意，Pandas提供的覆盖并不完整，因此，使用(就地)Shift运算符确实有效：
>>> b = a << u.m
>>> b
<Quantity [1., 2., 3.] m>
>>> a <<= u.m
>>> a
<Quantity [1., 2., 3.] m>
但这是脆弱的，因为如果Pandas决定覆盖DUnder方法，这可能会在未来的Pandas版本中停止工作。
Numpy数组创建函数不能用于初始化数量#
尝试以下示例将忽略该设备：
>>> np.full(10, 1 * u.m)
array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1.])
目前解决这个问题的方法是：
>>> np.full(10, 1) << u.m
<Quantity [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.] m>
以及与 full 一个人做不到 zeros ， ones 和 empty .
这个 arange 函数也不起作用：：
>>> np.arange(0 * u.m, 10 * u.m, 1 * u.m)
Traceback (most recent call last):
...
TypeError: only dimensionless scalar quantities can be converted to Python scalars
解决方法包括将设备移出呼叫以 arange **
>>> np.arange(0, 10, 1) * u.m
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>
另外， linspace 是否有效：
>>> np.linspace(0 * u.m, 9 * u.m, 10)
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>
广播时数量会失去单位#
广播数量时，必须通过 subok=True 到 broadcast_to 或者一个裸体 ndarray 将返回：
>>> q = u.Quantity(np.arange(10.), u.m)
>>> b = np.broadcast_to(q, (2, len(q)))
>>> b
array([[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]])
>>> b2 = np.broadcast_to(q, (2, len(q)), subok=True)
>>> b2
<Quantity [[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]] m>
这类似于将数量传递给 array ：：
>>> a = np.array(q)
>>> a
array([0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
>>> a2 = np.array(q, subok=True)
>>> a2
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>
链式数量与无因次零的比较可能会产生误导#
使用数量和无因次零链接比较时，结果可能会产生误导：
>>> 0 * u.Celsius == 0 * u.m # Correct
False
>>> 0 * u.Celsius == 0 == 0 * u.m # Misleading
True
第二个比较真正做的是：
>>> (0 * u.Celsius == 0) and (0 == 0 * u.m)
True
的mmap支持 astropy.io.fits 在GNU赫德#
在赫德和其他平台上， flush() 内存映射文件没有实现，因此向mmap的FITS文件写入更改可能不可靠，因此被禁用。尝试使用mmap以可写模式打开FITS文件将导致警告（并且mmap将自动在文件上禁用）。
Windows上的彩色打印#
日志消息和其他彩色文本的彩色打印在Windows中也可以工作，但只有在IPython控制台中运行时才可以。Windows上的基本Python命令行解释器当前不支持颜色。
numpy.int64 不分解输入 Quantity 物体#
Python 的 int() 通过 __index__ 而当 numpy.int64 或 numpy.int_ 不要通过 __index__ 。这意味着需要在NumPy中进行上游修复，以便 astropy.units 要控制分解这些函数中的输入，请执行以下操作：
>>> np.int64((15 * u.km) / (15 * u.imperial.foot))
1
>>> np.int_((15 * u.km) / (15 * u.imperial.foot))
1
>>> int((15 * u.km) / (15 * u.imperial.foot))
3280
转换无量纲 Quantity 因此，建议使用 int(...) .
构建/安装/测试问题#
Anaconda用户应该使用 conda ，不是 pip#
升级 astropy 在 Python Python发行版中使用 pip 可能导致旧版本和新版本的文件混合在一起的损坏安装。Anaconda用户应使用更新 conda update astropy . 在 astropy 关于PyPI及其通过 conda 包管理器；用户可以使用 conda search astropy .
MacOS X和Linux中的区域设置错误#
在MacOSX上，运行时可能会看到以下错误 pip ：：
...
ValueError: unknown locale: UTF-8
这是由于 LC_CTYPE 环境变量未正确设置为 UTF-8 默认情况下，这不是有效的区域设置。
在MacOS X或Linux（或其他平台）上，您可能还会遇到以下错误：
...
stderr = stderr.decode(stdio_encoding)
TypeError: decode() argument 1 must be str, not None
这也表明您的区域设置不正确。
若要修复这些问题中的任何一个，请设置此环境变量以及 LANG 和 LC_ALL 环境变量，例如。 en_US.UTF-8 使用，在 bash ：：
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
为了避免将来出现任何问题，您应该将这一行添加到您的示例中。 ~/.bash_profile 或 .bashrc 文件。
要测试这些更改，请打开新的端子并键入 locale ，你应该看到这样的东西：
$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
如果是这样，你可以继续尝试跑步 pip 再次（在新航站楼）。
在IPython中运行测试时日志记录测试失败#
When running the Astropy tests using astropy.test() in an IPython
interpreter, some of the tests in the astropy/tests/test_logger.py might
fail depending on the version of IPython or other factors.
This is due to mutually incompatible behaviors in IPython and pytest, and is
not due to a problem with the test itself or the feature being tested.
安装asdf-Astopy后，测试运行器失败#
当你有了 asdf-astropy 已安装，然后运行 astropy.test() ，您将看到一个回溯，它抱怨以下方面：
PytestAssertRewriteWarning: Module already imported so cannot be rewritten: asdf
奔跑 astropy.test() 无论如何，请先卸载 asdf-astropy 。如果您不想这样做，请使用 pytest 或 tox 而不是试跑者。