Ole Streicher

I think it is not urgent, as we can just disable the astroquery test for the moment (@ViviCoder, right?). The failure however suggests me that without a fix, some real...

Another, less invasive change would be to patch the heuristics on `OverflowError` here: https://github.com/astropy/astropy/blob/02d09506d1e02e4ae8b8b05f6813362a982e70bf/astropy/io/ascii/core.py#L1094-L1102 Changing this to first try `numpy.int64`, and use `str` only as really last resort could probably...

Another related issue is that when using the `str` fallback, the column type must be updated. Otherwise, the attempt will fail here: https://github.com/astropy/astropy/blob/02d09506d1e02e4ae8b8b05f6813362a982e70bf/astropy/io/ascii/core.py#L1084-L1086

To me, this looks even more complicated than before. To get close to the original behavior, we could also * add `np.int64` only if it is not equivalent to `int`...

I am not sure about the usefulness of the warning at all; I don't see a big difference between a `TypeError`/`ValueError` and the `OverflowError`: Why should one take the first...

One other issue here is that the np.array parser is a bit weird: ```Python >>> import numpy as np >>> np.array('12345678', np.int8) array(78, dtype=int8) >>> np.array('12345678', np.int16) array(24910, dtype=int16) >>>...

I am still wondering what the difference between `u.mag()` and `u.mag` from the user perspective is. What is the use case for `u.mag` at all? If we could make `u.mag`...

I still don't see the difference between `u.mag` and the dimensionless `u.mag()`. And to me, `STmag/arcsec²` looks dangerously sloppy; IMO it should be written as `mag(ST/arcsec²)`.

@plim Not really, but the other way: ST is a flux unit; `mag(ST)` converts it to a magnitude. If one wants to convert a surface flux, the natural way is...

The installation is actually configured by patching `mkiraf.sh`, `setup.sh` and `ecl.sh` resp. `irafcl.sh` to set the iraf root in the installation, so that these commands work without `etc/iraf/irafroot`. What would...