'WCS.allworld2pix' failed to converge when plotting WCS with non linear distortions <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --When trying to plot an image with a WCS as projection that contains non linear Distortions it fails with a error. When I add as parameter to the call at line 326 of I get the good enough looking plot below: ! It would be nice if there was a way of getting that plot without having to hack the library code like that. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --The call to plotting the grid fails with the following error (last few lines, can provide more if necessary): <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks ( from import WCS, Sip import numpy as np import as plt wcs = WCS(naxis=2) a = [[ 0.+00, 0.+00, 6.-07, -1.-10], [ 0.+00, 9.-06, -1.-07, 0.+00], [ 7.-06, 2.-09, 0.+00, 0.+00], [-1.-07, 0.+00, 0.+00, 0.+00]] b = [[ 0.+00, 0.+00, 1.-05, -1.-07], [ 0.+00, 5.-06, -1.-09, 0.+00], [ 1.-05, -1.-07, 0.+00, 0.+00], [ 3.-09, 0.+00, 0.+00, 0.+00]] crpix = [1221., 994.] ap = bp = ((4, 4)) = Sip(a, b, ap, bp, crpix) plt.subplot(projection=wcs) (((1944, 2592))) (color='white', ls='solid') import platform; print(platform.platform()) Linux-5.11.10-arch1-1-x8664-with-glibc2.33 import sys; print("Python", sys.version) Python 3.9.2 (default, Feb 20 2021, 18:40:11) [GCC 10.2.0] import numpy; print("Numpy", numpy.version) Numpy 1.20.2 import astropy; print("astropy", astropy.version) astropy 4.3.dev690+g7811614f8 import scipy; print("Scipy", scipy.version) Scipy 1.6.1 import matplotlib; print("Matplotlib", matplotlib.version) Matplotlib 3.3.4 pixel = self.allworld2pix(worldarrays, 0) ~/work/develop/env/lib/python3.9/site- in worldtopixelvalues(self, worldarrays) 324 325 def worldtopixelvalues(self, worldarrays): --326 pixel = self.allworld2pix(worldarrays, 0) 327 return pixel[0] if self.pixelndim == 1 else tuple(pixel) 328 ~/work/develop/env/lib/python3.9/site- in wrapper(args, kwargs) 534 (message, warningtype, stacklevel=2) 535 --536 return function(args, kwargs) 537 538 return wrapper ~/work/develop/env/lib/python3.9/site- in allworld2pix(self, tolerance, maxiter, adaptive, detectdivergence, quiet, args, kwargs) 1886 raise ValueError("No basic WCS settings were created.") 1887 -1888 return self.arrayconverter( 1889 lambda args, kwargs: 1890 self.allworld2pix( ~/work/develop/env/lib/python3.9/site- in arrayconverter(self, func, sky, radecorder, args) 1335 "a 1-D array for each axis, followed by an origin.") 1336 -1337 return returnlistofarrays(axes, origin) 1338 1339 raise TypeError( ~/work/develop/env/lib/python3.9/site- in returnlistofarrays(axes, origin) 1289 if radecorder and sky == 'input': 1290 xy = self.denormalizesky(xy) -1291 output = func(xy, origin) 1292 if radecorder and sky == 'output': 1293 output = self.normalizesky(output) ~/work/develop/env/lib/python3.9/site- in <lambda(args, kwargs) 1888 return self.arrayconverter( 1889 lambda args, kwargs: -1890 self.allworld2pix( 1891 args, tolerance=tolerance, maxiter=maxiter, 1892 adaptive=adaptive, detectdivergence=detectdivergence, ~/work/develop/env/lib/python3.9/site- in allworld2pix(self, world, origin, tolerance, maxiter, adaptive, detectdivergence, quiet) 1869 slowconv=ind, divergent=None) 1870 else: -1871 raise NoConvergence( 1872 "'WCS.allworld2pix' failed to " 1873 "converge to the requested accuracy.\n" NoConvergence: 'WCS.all_world2pix' failed to converge to the requested accuracy. After 20 iterations, the solution is diverging at least for one input point. ) around your code snippet. --<!-- If necessary, sanitize your screen output to be pasted so you do not reveal secrets like tokens and passwords. --Here is the code to reproduce the problem: <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --


Add helpers to convert between different types of uncertainties Currently there no easy way to convert from an arbitrary uncertainty class to a different uncertainty class. This would be useful to be able to pass NDData objects to external libraries/tools which assume, for example, that uncertainties will always stored as variances. Here's some really scrappy code I bunged together quickly for my purposes (probably buggy, I need to properly test it), but what are peoples opinions on what's the best API/design/framework for such a system?


BlackBody bolometric flux is wrong if scale has units of dimensionlessunscaled The class has the wrong bolometric flux if argument is passed as a Quantity with units, but the correct bolometric flux if is simply a float. <!-- Provide a general description of the bug. --Expected output from sample code: Actual output from sample code: Sample code:


Can Table masking be turned off? <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Provide a general description of the feature you would like. --<!-- If you want to, you can suggest a draft design or API. --<!-- This way we have a deeper discussion on the feature. --As of Astropy 5, when encounters values such as , it automatically creates a and the whole table becomes a . While this might be useful for individual end-users, it is very inconvenient for intermediate data in pipelines. Here's the scenario: data are being passed via files and . A downstream function needs to replace with valid values. Previously those values could be easily identified (e.g. and replaced. However, now additional work is need to look "underneath" the mask, extracting the actual values, replacing them, and then possibly creating a new, unmasked column, or even an entirely new table. Ideally, a keyword like would disable this behavior, for people who don't need this masking.


SkyCoord in Table breaks aggregate on groupby When putting a column of s in a , does not work on : fails with This happens irregardless of the aggregation function. Aggregation works, only fails to aggregate columns where operation does not make sense. and


No longer able to read BinnedTimeSeries with datetime column saved as ECSV after upgrading from 4.2.1 -5.0+ <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Hi, merged in PR breaks my ability to read an ECSV file created using Astropy v 4.2.1, BinnedTimeSeries class's write method, which has a datetime64 column. Downgrading astropy back to 4.2.1 fixes the issue because the strict type checking in line 177 of is not there. Is there a reason why this strict type checking was to ECSV? Is there a way to preserve reading and writing of ECSV files created with BinnedTimeSeries across versions? I am happy to make a PR on this if the strict type checking is allowed to be scaled back or we can add datetime64 as an allowed type. <!-- What did you expect to happen. --The file is read into a object from ecsv file without error. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --ValueError is produced and the file is not read because does not accept the datetime64 column. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks ( ValueError Traceback (most recent call last) Input In [3], in <module---49 tsrbin = ('', format='') File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in (self, filename, timebinstartcolumn, timebinendcolumn, timebinsizecolumn, timebinsizeunit, timeformat, timescale, format, args, kwargs) 230 """ 231 Read and parse a file and returns a . 232 (...) 279 280 """ 282 try: 283 284 # First we try the readers defined for the BinnedTimeSeries class --285 return super().read(filename, format=format, args, kwargs) 287 except TypeError: 288 289 # Otherwise we fall back to the default Table readers 291 if timebinstartcolumn is None: File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in (self, args, kwargs) 59 units = ('units', None) 60 descriptions = ('descriptions', None) ---62 out = (cls, args, kwargs) 64 # For some readers (e.g., ), the returned class is not 65 # guaranteed to be the same as the desired output . If so, 66 # try coercing to desired class without copying ( 67 # would normally do a copy). The normal case here is swapping 68 # Table <=QTable. 69 if cls is not File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in (self, cls, format, cache, args, kwargs) 195 format = self.getvalidformat( 196 'read', cls, path, fileobj, args, kwargs) 198 reader = self.getreader(format, cls) --199 data = reader(args, kwargs) 201 if not isinstance(data, cls): 202 # User has read with a subclass where only the parent class is 203 # registered. This returns the parent class, so try coercing 204 # to desired subclass. 205 try: File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in ioread(format, filename, kwargs) 16 format = (r'^ascii.', '', format) 17 kwargs['format'] = format ---18 return read(filename, kwargs) File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in read(table, guess, kwargs) 374 else: 375 reader = getreader(newkwargs) --376 dat = (table) 377 ({'kwargs': copy.deepcopy(newkwargs), 378 'Reader': , 379 'status': 'Success with specified Reader class ' 380 '(no guessing)'}) 382 # Static analysis (pyright) indicates might be left undefined, so just 383 # to be sure define it at the beginning and check here. File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in (self, table) 1340 (, ) 1342 # Get the table column definitions -1343 () 1345 # Make sure columns are valid 1346 (, self.strictnames, self.guessing) File ~/Apps/miniconda3/envs/py310latest/lib/python3.10/site-, in EcsvHeader.getcols(self, lines) 175 = headercols[]['datatype'] 176 if not in ECSVDATATYPES: --177 raise ValueError(f'datatype {!r} of column {!r} ' 178 f'is not in allowed values {ECSVDATATYPES}') 180 # Subtype is written like "int64[2,null]" and we want to split this 181 # out to "int64" and [2, None]. 182 subtype = col.subtype ValueError: datatype 'datetime64' of column 'timebinstart' is not in allowed values ('bool', 'int8', 'int16', 'int32', 'int64', 'uint8', 'uint16', 'uint32', 'uint64', 'float16', 'float32', 'float64', 'float128', 'string') <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --(For the version that does not work) Python 3.10.2 (main, Feb 1 2022, 19:28:35) [GCC 9.4.0] Numpy 1.22.2 pyerfa 2.0.0.1 astropy 5.0.1 Scipy 1.8.0 Matplotlib 3.5.1 (For the version that does work) Python 3.7.11 (default, Jul 27 2021, 14:32:16) [GCC 7.5.0] Numpy 1.20.3 pyerfa 2.0.0.1 astropy 4.2.1 Scipy 1.7.0 Matplotlib 3.4.2


The keyword argument of is not supported for instances. <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Provide a general description of the feature you would like. --<!-- If you want to, you can suggest a draft design or API. --<!-- This way we have a deeper discussion on the feature. --Apologies if there is a duplicate somewhere, I scoured all the issues for this problem and I couldn't find it mentioned yet. The keyword argument was to and all the other -based functions in version 1.20.0 of numpy, but it doesn't seem to work yet with . Does anyone know if there is some limitation in that is preventing this feature from being implemented? If not, I could put some time towards updating to support this feature. <!-- Add any other context or screenshots about the feature request here. --<!-- This part is optional. --


Modeling's does not compute separability correctly for nested CompoundModels Consider the following model: It's separability matrix as you might expect is a diagonal: If I make the model more complex: The output matrix is again, as expected, the outputs and inputs to the linear models are separable and independent of each other. If however, I nest these compound models: Suddenly the inputs and outputs are no longer separable? This feels like a bug to me, but I might be missing something?


Convert CCDData to ImageHDU As far as I can tell, currently there's no way to directly convert a object to an object. If we write it to a file using it will always create a file where the first HDU is a that contains the , followed by optionally some s that contain mask or uncertainty. If we instead use , it will return an equivalent to the file it writes with , that is, the is stored in the first element of the , which is always a . This is somewhat unexpected given that you can already do it the other way around (that is, convert a object to a object): The problem is that if we then want to use this as an extension to another FITS file, there's no obvious way to get an which would allow us to do that. As far as I can tell, there's also no trivial way to convert a to a . We could manually create a new by copying the data from the , as well as its relevant cards and so on... but this seems unnecessarily complicated. I propose the following interfaces: This seems somewhat similar to the situation with and . In that case, we can also specify an parameter when reading: From here we can use:


Incorrect ignored usage in <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Providing inputs to does not always work as expected. Running the following code: Produces: This is incorrect. It instead should produce: Somehow the status of the input is being accounted for during the validation which occurs during the construction of the bounding box; however, it is getting "lost" somehow resulting in the weird behavior we see above. Oddly enough ignoring does not have an issue. E.G. this code: Produces: as expected. This is present in both astropy 5.03 and astropy develop


TimeSeries: misleading exception when required column check fails. <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --For a object that has additional required columns (in addition to ), when codes mistakenly try to remove a required column, the exception it produces is misleading. <!-- What did you expect to happen. --An exception that informs the users required columns are missing. The actual exception message is confusing: <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python from import Time from astropy.timeseries import TimeSeries time=Time((, ), format='jd') ts = TimeSeries(time=time, data = {"flux": [99.9, 99.8, 99.7]}) ts.requiredcolumns = ["time", "flux"] ts.remove_column("flux") Windows-10-10.0.-SP0 Python 3.9.10 (main, Feb 1 2022, 21:21:54) [MSC v.1929 64 bit (AMD64)] Numpy 1.22.3 pyerfa 2.0.0.1 astropy 5.0.3 Scipy 1.8.0 Matplotlib 3.5.1


Time from not precise Hello, I encounter difficulties with Time. I'm working on a package to perform photometry and occultation. For this last case, data need times values accurately estimated. Of course, data coming from different camera will will have different time format in the header. to manage this without passing long time to build a time parser, i decided to use Time object which do exactly what i need. The problem is, i dont arrive to make accurate conversion between different format using Time. let's do an exemple: now let's do reverse as you can see i don't fall back on the same value and the difference is quite high. I would like to fall back on the original one. thank you in advance


Document reading True/False in ASCII table as bool not str <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Provide a general description of the feature you would like. --<!-- If you want to, you can suggest a draft design or API. --<!-- This way we have a deeper discussion on the feature. -- showed a use case for having an ASCII table column consisting of only "True" and "False" be read as instead of (current behavior). That issue discusses reasons to maintain the current behavior, but there are simple workarounds discussed there that should be brought out to the narrative docs as examples for users. I'd suggest the following as a recommendation for users: This new information could go in the existing section on in the read documentation. <!-- Add any other context or screenshots about the feature request here. --<!-- This part is optional. -- Control dtype with (converters API needs better doc or refactoring) I cannot find a way to control the dtype of the output table when reading a file into a . Consider the following MWE, with 3 numerical columns, while one of them would preferably be kept as a string: Reading in the same with and then converting to a Table works, but it should ideally be supported directly.


Register format with nice mathjax Cosmology can now read and write to files. It would be nice to register with a method for exporting a Cosmology to a HTML table. There are good examples of IO with Cosmology at and documentation at I'm thinking the (..., format='html'). Edit: also, the mathjax representation of each parameter can be stored on the corresponding Parameter object, like how units have the argument in .


Add arrayfunc for <!-- This comments are hidden when you submit the pull request, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- If you are new or need to be re-acquainted with Astropy contributing workflow, please see . There is even a practical example at . --<!-- Astropy coding style guidelines can be found here: Our testing infrastructure enforces to follow a subset of the PEP8 to be followed. You can check locally whether your changes have followed these by running the following command: tox -e codestyle --<!-- Please just have a quick search on GitHub to see if a similar pull request has already been posted. We have old closed pull requests that might provide useful code or ideas that directly tie in with your pull request. --<!-- We have several automatic features that run when a pull request is open. They can appear daunting but do not worry because maintainers will help you navigate them, if necessary. --<!-- Provide a general description of what your pull request does. Complete the following sentence and add relevant details as you see fit. --<!-- In addition please ensure that the pull request title is descriptive and allows maintainers to infer the applicable subpackage(s). --<!-- READ THIS FOR MANUAL BACKPORT FROM A MAINTAINER: Apply "skip-basebranch-check" label before you open the PR! --xref This provides some numpy array functions for objects. Most notably, one can now do the following without an errror(!): This still needs: [ ] Tests [ ] What's new [ ] API docs??? but opening now for feedback and a full CI run. <!-- If the pull request closes any open issues you can add this. If you replace <Issue Numberwith a number, GitHub will automatically link it. If this pull request is unrelated to any issues, please remove the following line. --<!-- This section is to be filled by package maintainer(s) who will review this pull request. --This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive. [x] Do the proposed changes actually accomplish desired goals? ? ? ? . [ ] Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the label. [ ] Is a change log needed? If yes, did the change log check pass? If no, add the label. If this is a manual backport, use the label unless special changelog handling is necessary. [ ] Is a milestone set? Milestone must be set but check might be missing; do not let the green checkmark fool you. [ ] At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate label(s) before merge.


Angle bug for (d, m, s) tuple input (deprecate dmstodegrees) does not handle the sign correctly for a tuple input if : <!-- Provide a general description of the bug. --fix for the issue (Angle bug for (d, m, s) tuple input (deprecate dmstodegrees)) fix for the issue Two solutions are proposed. code for solution 1 is presented in this pull request.


Structured column serialization round-trip fails with field name of "name" <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --A structured column with a field name of cannot be round-tripped through ECSV. Along with this suggests a tweak to the serialization format is needed. Perhaps: cc: <!-- What did you expect to happen. --It should work! <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import io import numpy as np from import Table, Column dtype = ([('z', 'f8'), ('name', 'f8'), ('y', 'i4')]) t = Table() t['c'] = Column([(1, 2, 3), (4, 5, 6)], dtype=dtype) out = io.StringIO() t.write(out, format='') print(out.getvalue()) t2 = (out.getvalue(), format='') c.z c.name c.y 0 2.0 3 0 5.0 6 Traceback (most recent call last): File in <modulet2 = (out.getvalue(), format='') File in call out = (cls, args, kwargs) File in read data = reader(args, kwargs) File in ioread return read(filename, **kwargs) File in read dat = (table) File in read table = self.outputter(, ) File in call out = serialize.constructmixinsfromcolumns(out) File in constructmixinsfromcolumns constructmixinfromcolumns(newname, objattrs, out) File in constructmixinfromcolumns dataattrsmap[val['name']] = name TypeError: unhashable type: 'SerializedColumn' macOS-10.16-x8664-i386-64bit Python 3.8.12 (default, Oct 12 2021, 06:23:56) [Clang 10.0.0 ] Numpy 1.22.2 pyerfa 2.0.0.1 astropy 5.1.dev956+g1d10de9d45. Scipy 1.8.0 Matplotlib 3.5.1


Consider removing auto-transform of structured column into NdarrayMixin <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Provide a general description of the feature you would like. --<!-- If you want to, you can suggest a draft design or API. --<!-- This way we have a deeper discussion on the feature. --Currently if you add a structured to a Table, it gets turned into an (via the code below). While this mostly works, I am not sure this is necessary or desirable any more after . Basically the original rational for was that structured dtype didn't quite work, in particular for serialization. So we pushed that out to a mixin class which would signal to unified I/O that it might not be supported. Proposal: Add a FutureWarning here telling the user to wrap in and that in the future (5.2) the structured array will be as a . Change the behavior in 5.2 by removing this clause. This is not critical for 5.1 but if we have the opportunity due to other (critical) bugfixes it might be nice to save 6 months in the change process. cc:


vstack'ing structured array tables fails with casting error <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Using on tables containing columns backed by numpy structured arrays fails. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python a=Table([dict(field1='test',field2=(1.,0.5,1.5))]) b=Table([dict(field1='foo')]) ((a,b)) # works a=Table([dict(field1='test',field2=(1.,0.5,1.5))],dtype=[str,[('val','f4'),('min','f4'),('max','f4')]]) ((a,b)) # fails Traceback (most recent call last): Input In [45] in <cell line: ((a,b)) File in vstack out = vstack(tables, jointype, colnamemap, metadataconflicts) File in vstack col[idx0:idx1] = array[name] File in setitem [index] = value TypeError: Cannot cast array data from dtype([('val', '<f4'), ('min', '<f4'), ('max', '<f4')]) to dtype('V12') according to the rule 'unsafe' macOS-12.3.1-x86_64-i386-64bit Python 3.10.4 (main, Apr 26 2022, 19:42:59) [Clang 13.1.6 (clang-1316.0.21.2)] Numpy 1.22.3 pyerfa 2.0.0.1 astropy 5.2.dev92+gf0e2129aa Scipy 1.7.3 Matplotlib 3.5.2


A direct approach to ITRS to Observed transformations that stays within the ITRS. <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Provide a general description of the feature you would like. --<!-- If you want to, you can suggest a draft design or API. --<!-- This way we have a deeper discussion on the feature. --We have experienced recurring issues raised by folks that want to observe satellites and such (airplanes?, mountains?, neighboring buildings?) regarding the apparent inaccuracy of the ITRS to AltAz transform. I tire of explaining the problem of geocentric versus topocentric aberration and proposing the entirely nonintuitive solution laid out in . So, for the latest such issue (), I came up with a more direct approach. This approach stays entirely within the ITRS and merely converts between ITRS, AltAz, and HADec coordinates. I have put together the makings of a pull request that follows this approach for transforms between these frames (i.e. ITRS<-AltAz, ITRS<-HADec). One feature of this approach is that it treats the ITRS position as time invariant. It makes no sense to be doing an ITRS-ITRS transform for differing between the input and output frame, so the of the output frame is simply adopted. Even if it ends up being in the case of an or output frame where that is the default. This is because the current ITRS-ITRS transform refers the ITRS coordinates to the SSB rather than the rotating ITRF. Since ITRS positions tend to be nearby, any transform from one time to another leaves the poor ITRS position lost in the wake of the Earth's orbit around the SSB, perhaps millions of kilometers from where it is intended to be. Would folks be receptive to this approach? If so, I will submit my pull request. <!-- Add any other context or screenshots about the feature request here. --<!-- This part is optional. --Here is the basic concept, which is tested and working. I have yet to add refraction, but I can do so if it is deemed important to do so:


Masked doesn't work on some structured arrays The dispatch function doesn't work on arrays with strutcured dtypes. Masked arrays with structured dtypes can be printed no prob, like their non-masked counterparts. It errors because of the structured dtype. Here's an example: While the following works: macOS-10.16-x8664-i386-64bit Python 3.9.12 (main, Jun 1 2022, 06:36:29) [Clang 12.0.0 ] Numpy 1.22.3 pyerfa 2.0.0.1 astropy 5.2.dev131+ga2da0589eb. Scipy 1.8.1 Matplotlib 3.5.2


FITS problem reading binary table with variable length columns I want to read a certain FITS file (), which is part of a Multi-Beam-FITS measurement set () as used by several radio observatories around the world. The file has a binary table extension with variable length columns. Usually this works fine, but this particular example has some columns with a "1PJ(1)" type (and one row only), which seems to lead to problems when reading with Here it appears already, that the content of the record ("(1, 1)"] is smaller than the 'itemsize' (109). In fact, accessing the first two columns works, but all var-length columns raise an error: I checked the file with , which results in zero warnings and errors. Thanks a lot for your help! Multi-dimensional arrays in variable-length array columns of a FITS binary table cause file corruption may create corrupted files when writing a to a file, if that table contains a variable-length array (VLA) column with arrays that have two (or more) dimensions. No warnings or errors are raised while writing, yet the resulting file may be unreadable to . Being able to write any n-dimensional arrays to a VLA column, writing that to a file and then successfully reading the column (round-trip). The resulting file is partially or even completely corrupted. a two-dimensional array and place it on a array with a VLA column with that array a from that column and write it to a file the file back Produces the following error: _ Playing around with it a bit more, I could produce some other weird behaviors. Outputs the following: while the expected result would be: So it seems that everything that doesn't fit in the first dimension is going out of bounds and writing over the next array. This explains why it can also heavily corrupt the file. _ Reading the FITS standard, I get the impression that multi-dimensional VLAs should be possible, so this seems like an unexpected behavior. At the very least, if multi-dimensional VLAs aren't meant to be supported, should be throwing errors. Right now it's simply failing silently. Windows-10-10.0.-SP0 Python 3.9.9 (tags/v3.9.9:, Nov 15 2021, 18:08:50) [MSC v.1929 64 bit (AMD64)] Numpy 1.22.2 pyerfa 2.0.0.1 astropy 5.0.1 Scipy 1.7.1


[Security] Jquery 3.1.1 is vulnerable to untrusted code execution <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code (see and ) <!-- What did you expect to happen. --Update jquery to the version 3.5 or newer in <!-- What actually happened. --<!-- Was the output confusing or poorly described? --jquery version 3.1.1 is distributed with the latest astropy release <!-- ### Steps to Reproduce <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python --<!--### System Details <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --


ASCII table output to HTML does not support supplied "formats" <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --When writing out an astropy table to HTML format, the option to the  method seems to be ignored. It does work when writing out to other formats, e.g., rst, CSV, MRT, etc. <!-- What did you expect to happen. --I expect the HTML table output to respect the formatting given by the argument. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --The argument seems to be ignored and the output is not formatted as required. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python from import Table from io import StringIO t = Table([(1.-24, 3.-15), (2, 4)], names=('a', 'b')) tc = t.copy() # copy table with StringIO() as sp: (sp, format="html", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) <html<head<meta charset="utf-8"/<meta content="text/html;charset=UTF-8" http-equiv="Content-type"/</head<body<table<thead<tr<tha</th<thb</th</tr</thead<tr<td1.-24</td<td2</td</tr<tr<td3.-15</td<td4</td</tr</table</body</htmlpython with StringIO() as sp: (sp, format="csv", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) a,b 24e-24,2 23e-15,4 python with StringIO() as sp: (sp, format="", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) ======== = a b ======== = 24e-24 2 23e-15 4 ======== = ) around your code snippet. --<!-- If necessary, sanitize your screen output to be pasted so you do not reveal secrets like tokens and passwords. --Outputting a HTML table gives the numbers to the full number of decimal places. Instead, outputting to a CSV table: or, e.g., rsrt: gives the formatting as expected. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --Linux-5.4.0-121-generic-x86_64-with-glibc2.31 Python 3.9.12 (main, Jun 1 2022, 11:38:51) [GCC 7.5.0] Numpy 1.22.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.8.1 Matplotlib 3.5.2


TST: failed in pyinstaller (computed error is different depending on the order of the arguments) First failing log (2022-03-13): Last successful log (2022-03-12): Looks like this test was in . Any idea how to fix, or ?


rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.


Can't convert a list of Astropy tables to a NumPy array of tables I recently stumbled upon where someone likes to convert a list of Tables to a NumPy array. By default, NumPy will convert the Table along the way, resulting in the wrong data structure. Using a specific , however, fails with This error leads directly to the source of , which explicitly checks for any to be not , which will raise the error. The reasoning behind that is clear, as given in the comments below. But I wonder if an exception is reasonable for here, and let that pass through. For a single Table, this may be odd, but not necessarily incorrect. And for a list of Tables, to be converted to an array, this may be helpful.


Comparing Frame with data and SkyCoord with same data raises exception <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --instances and instances with data are somewhat used interchangebly and I am still not sure after all this time spending with astropy what is preferable when... So it's a bit surprising to me, that comparing a frame with data to a instance with exactly the same data raises an exception: python In [1]: from astropy.coordinates import SkyCoord, ICRS In [2]: frame = ICRS("0d", "0d") In [3]: coord = SkyCoord(frame) In [4]: frame == coord TypeError Traceback (most recent call last) Input In [4], in <cell line: 1() ----1 frame == coord File , in (self, value) 1651 def eq(self, value): 1652 """Equality operator for frame. 1653 1654 This implements strict equality and requires that the frames are 1655 equivalent and that the representation data are exactly equal. 1656 """ -1657 isequiv = self.isequivalentframe(value) 1659 if is None and is None: 1660 # For Frame with no data, == compare is same as isequivalentframe() 1661 return isequiv File , in BaseCoordinateFrame.isequivalentframe(self, other) 1358 return True 1359 elif not isinstance(other, BaseCoordinateFrame): -1360 raise TypeError("Tried to do isequivalentframe on something that " 1361 "isn't a frame") 1362 else: 1363 return False TypeError: Tried to do isequivalentframe on something that isn't a frame <!-- What did you expect to happen. --Compare to true / false depending on data. Exception


Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?


Inconsistent behavior of in <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --I have a 3D WCS with dimensions corresponding to space, space, and wavelength and what some might call a non-trivial PCij matrix that couples the spectral and spatial dimensions. I find that when I perform a worldtopixel on the full (unsliced) WCS, I get back the expected result. However, when I perform that same worldtopixel operation on a single wavelength slice (i.e. a 2D slice with dimensions corresponding to space, space), my worldtopixel returns an erroneous result for one of the dimensions. This issue was originally posted as sunpy/ndcube, but I've moved it here as it seems to be an issue with rather than anything specific to . <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import numpy as np import from astropy.coordinates import SkyCoord import as u nx = 100 ny = 25 nz = 2 wcsheader = { 'WCSAXES': 3, 'CRPIX1': (nx + 1)/2, 'CRPIX2': (ny + 1)/2, 'CRPIX3': 1.0, 'PC11': 0.0, 'PC12': -1.0, 'PC13': 0.0, 'PC21': 1.0, 'PC22': 0.0, 'PC23': -1.0, 'CDELT1': 5, 'CDELT2': 5, 'CDELT3': 0.055, 'CUNIT1': 'arcsec', 'CUNIT2': 'arcsec', 'CUNIT3': 'Angstrom', 'CTYPE1': 'HPLN-TAN', 'CTYPE2': 'HPLT-TAN', 'CTYPE3': 'WAVE', 'CRVAL1': 0.0, 'CRVAL2': 0.0, 'CRVAL3': 1.05, } fitswcs = (header=wcsheader) python pt = SkyCoord(, , (fitswcs)) fitswcs.worldtopixel(pt, 1.05u.angstrom) (array(49.5), array(12.), array(2.-15)) python llslicedwcs = (fitswcs, 0) hlslicedwcs = (llslicedwcs) hlslicedwcs.worldtopixel(pt) (array(1.+11), array(12.)) python px,py,pz = fitswcs.worldtopixel(pt, 1.05u.Angstrom) fitswcs.pixeltoworld(px, py, pz) [<SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.), <SpectralCoord 1.05e-10 m] hlslicedwcs.pixeltoworld(px, py) <SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.)macOS-10.16-x8664-i386-64bit Python 3.9.7 (default, Sep 16 2021, 08:50:36) [Clang 10.0.0 ] Numpy 1.21.5 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.8.0 Matplotlib 3.5.1


throws exception with <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --The decorator throws a when used on a function that returns a with and a return type annotation. <!-- What did you expect to happen. --For the function to return a with with the appropriate units or to throw an exception if the output units are of the wrong type. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --Using the decorator results in a gives <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --


wcslint crashes on valid WCS calls an underlying function here: Looks like all it does is tries to create a object with the header and report warnings, so the bug is either inside or it is a matter of updating on how validator calls in more complicated cases: File: File: File: (Reported by


parses fractional days in year-month-day format incorrectly results in : the fractional days are interpreted as fractional seconds ( is what I hoped for). The format is perhaps not the best format, but it is used, and since Astropy does not raise an exception, but silently returns an incorrect result, this may lead to errors. The issue can be traced to , which will interpret anything right of the last dot as a fractional second. Since matching to regexes or formats is done afterwards, there is no (easy) way to catch this through a subformat before the fractional second get stripped. I'd be happy to try and put in a PR for this (if it's indeed a bug), but I'll need to know whether to raise an exception, or implement a proper parser for this format (provided it doesn't clash with other interpretations). Some suggestions on the best way to attack this issue (or at what point in the code) are welcome as well.


Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.


float32 representation of pi/2 is rejected by <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --The closest float32 value to pi/2 is by accident slightly larger than pi/2: Astropy checks using float64 precision, rejecting "valid" alt values (e.g. float32 values read from files): Be lenient? E.g. only make the comparison up to float 32 precision? See error above See snippet above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --


Printing tables doesn't work correctly with 0-length array cells


Creating a mixin column in a new table from columns of another table renames columns in original table. Consider the following code, where a subset of columns from another table should be included in a new table with new names, prerably without copying the actual payload data: If any of the two classes or both are a , not a , the code works as expected. Data in the columns is not copied, but column names in original table stay the same. Column names do change in both tables: See above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --(also tested with current branch)


Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1


Should return instead of raising if the inputs are incompatible? I'm trying to implement a duck type of . If you are interested, the project is available . I'm running into trouble trying to coerce my duck type to use the reflected versions of the arithmetic operators if the left operand is not an instance of the duck type and they have equivalent but different units. Consider the following minimal working example of my duck type. If I do an operation like It works as expected. Or I can do and it still works properly. But if the left operand has different units I get the following error: I would argue that should really return in this instance, since it would allow for to be called instead of the error being raised. I feel that the current behavior is also inconsistent with the which specify that should be returned if the requested operation is not implemented. What does everyone think? I am more than happy to open a PR to try and solve this issue if we think it's worth pursuing.


Degrees Celsius should be supported by FITS units <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --The FITS standards says that units should follow IAU recommendations. These note that: However, astropy does not support for fits: See


Subclassed SkyCoord gives misleading attribute access message I'm trying to subclass , and add some custom properties. This all seems to be working fine, but when I have a custom property ( below) that tries to access a non-existent attribute () below, the error message is misleading because it says doesn't exist, where it should say doesn't exist. raises


Should calling on instances with incompatible units return ? <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --Using on instances with incompatible units raises a . I would've expected this function just to return in this case. Do we think it's really necessary to halt if the units are incompatible? <!-- What actually happened. --An exception was raised. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python np.arrayequal([1, 2, 3] u.mm, [1, 2, 3] u.s) Traceback (most recent call last): File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 980, in tovalue scale = (unit) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1129, in to raise UnitConversionError(f"'{self!r}' is not a scaled version of '{other!r}'") 'Unit("s")' is not a scaled version of 'Unit("mm")' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Users\royts\AppData\Local\Programs\Python\Python310\lib\site-packages\IPython\core\", line 3378, in runcode exec(codeobj, self.userglobalns, ) File "<ipython-input-13-", line 1, in <modulenp.arrayequal([1, 2, 3] u.mm, [1, 2, 3] u.s) File "<arrayfunction internals", line 180, in arrayequal File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1844, in arrayfunction args, kwargs, unit, out = functionhelper(args, *kwargs) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\quantityhelper\", line 566, in arrayequal args, unit = quantities2arrays(a1, a2) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\quantityhelper\", line 351, in quantities2arrays arrays = tuple((q.toownunit(arg)) for arg in args) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\quantityhelper\", line 351, in <genexprarrays = tuple((q.toownunit(arg)) for arg in args) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1652, in toownunit value = value.tovalue(unit) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 983, in tovalue value = self.tovalue(unit, equivalencies) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 889, in tovalue return ( File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1165, in to return self.getconverter(Unit(other), equivalencies)(value) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1094, in getconverter raise exc File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1077, in getconverter return self.applyequivalencies( File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1054, in applyequivalencies raise UnitConversionError(f"{unitstr} and {other_str} are not convertible") 's' (time) and 'mm' (length) are not convertible Windows-10-10.0.-SP0 Python 3.10.8 (tags/v3.10.8:, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)] Numpy 1.23.5 pyerfa 2.0.0.1 astropy 5.3.dev89+g4989e530b Scipy 1.9.1 Matplotlib 3.6.0


Please support header rows in RestructuredText output It would be great if the following would work: RestructuredText output is a great way to fill autogenerated documentation with content, so having this flexible makes the life easier


The argument to -like functions does not accept instances of <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --When using , , etc. family of functions, with instances of , the argument only accepts instances of . I would have expected that the argument needs to be an instance of with compatible units. An is raised if is an instance of . <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import numpy as np import as u a = (21) u.m np.histogram(a, range=[.25, .75] u.m) Traceback (most recent call last): File "C:\Users\royts\AppData\Local\Programs\Python\Python310\lib\site-packages\IPython\core\", line 3378, in runcode exec(codeobj, self.userglobalns, ) File "<ipython-input-8-", line 1, in <modulenp.histogram(a, range=[.2, .7] u.m) File "<arrayfunction internals", line 200, in histogram File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 1844, in arrayfunction result = super().arrayfunction(function, types, args, kwargs) File "C:\Users\royts\AppData\Local\Programs\Python\Python310\lib\site-packages\numpy\lib\", line 824, in histogram keep = (tmpa = firstedge) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 699, in arrayufunc raise e File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\", line 644, in arrayufunc converters, unit = convertersandunit(function, method, inputs) File "C:\Users\royts\Kankelborg-Group\astropy\astropy\units\quantityhelper\", line 200, in convertersandunit raise UnitConversionError( Can only apply 'lessequal' function to dimensionless quantities when other argument is not a quantity (unless the latter is all zero/infinity/nan). Windows-10-10.0.-SP0 Python 3.10.8 (tags/v3.10.8:, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)] Numpy 1.24.0 pyerfa 2.0.0.1 astropy 5.3.dev128+ge512a6799 Scipy 1.9.1 Matplotlib 3.6.0


When should be linked to a new object? Mostly for - I noticed that in the way we have set up , is passed on not just for views (where it should be), but also for copies (implicitly in arithmetic operations, etc.). Which ones are reasonable? Just thinking about whether, e.g., should be propagated, I'd think: Surely for views & reshapes: , , etc. insertions: Probably for selection of scalars: or in (for columns this returns a scalar without ) copies: and equivalents equivalent unit changes: , , , etc. Probably not for operations real unit changes (including in-place??; ) What do you think? p.s. Currently, all of the above happen, in part because I use in , something which I don't think we had really considered when we made the change in . But that also means that in principle it may not too hard to fairly finely define the behaviour.


Presence of SIP keywords leads to ignored PV keywords. <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --I am working on updating the fits header for one of our telescopes. We wanted to represent the distortions in SIP convention and the projection to be 'CAR'. While working on this, I noticed if SIP coefficients are present in the header and/or '-SIP' is to CTYPEia keywords, astropy treats the PV keywords (PV10, PV11 and PV12) as "redundant SCAMP distortions". Earlier I could not figure out why the projection weren't going as I expected, and I suspected a bug in astropy wcs. After talking to Mark Calabretta about the difficulties I'm facing, that suspicion only grew stronger. The header was working as expected with WCSLIB but was giving unexpected behavior in astropy wcs. The following would be one example header - When you parse the wcs information from this header, the image should be centered at ra=120 and dec=29 with lines of constant ra and dec looking like the following image generated using wcslib - ! If I parse the wcs information using astropy wcs, it throws the following warning - And the resulting grid is different. Code - Grid - ! The astropy wcs grid/solution does not change whethere we keep or remove the PV keywords. Furthermore, the astropy grid can be recreated in wcslib, by removing the PV keywords. ! <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks () around your code snippet. --<!-- If necessary, sanitize your screen output to be pasted so you do not reveal secrets like tokens and passwords. --the header the header using the graticule the PV keywords and run again will find the same graticule indicating that PV keywords are completely ignored. Additionally, the graticules can be compared with the wcsgrid utility of wcslib. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --Linux-6.0.11-200.fc36.x8664-x8664-with-glibc2.35 Python 3.9.12 (main, Apr 5 2022, 06:56:58) [GCC 7.5.0] Numpy 1.21.5 pyerfa 2.0.0 astropy 5.1 Scipy 1.7.3 Matplotlib 3.5.1 Remove heuristic code to handle PTF files which is causing a bug <!-- This comments are hidden when you submit the pull request, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- If you are new or need to be re-acquainted with Astropy contributing workflow, please see . There is even a practical example at . --<!-- Astropy coding style guidelines can be found here: Our testing infrastructure enforces to follow a subset of the PEP8 to be followed. You can check locally whether your changes have followed these by running the following command: tox -e codestyle --<!-- Please just have a quick search on GitHub to see if a similar pull request has already been posted. We have old closed pull requests that might provide useful code or ideas that directly tie in with your pull request. --<!-- We have several automatic features that run when a pull request is open. They can appear daunting but do not worry because maintainers will help you navigate them, if necessary. --<!-- Provide a general description of what your pull request does. Complete the following sentence and add relevant details as you see fit. --<!-- In addition please ensure that the pull request title is descriptive and allows maintainers to infer the applicable subpackage(s). --<!-- READ THIS FOR MANUAL BACKPORT FROM A MAINTAINER: Apply "skip-basebranch-check" label before you open the PR! --Currently the function remove any PV keywords when SIP distortions are present and no radial terms are present which should not be the case. This function was put in place for solving but it causes the bug . We can either keep adding heuristic code to fix the edge cases as they come up with or remove and let the user deal with non-standard files. I'm opening a pull request for the latter following the discusison in . <!-- If the pull request closes any open issues you can add this. If you replace <Issue Numberwith a number, GitHub will automatically link it. If this pull request is unrelated to any issues, please remove the following line. -- <!-- This section is to be filled by package maintainer(s) who will review this pull request. --This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive. [ ] Do the proposed changes actually accomplish desired goals? ? ? ? . . [ ] Is a change log needed? If yes, did the change log check pass? If no, add the label. If this is a manual backport, use the label unless special changelog handling is necessary. [ ] Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied? [ ] Is a milestone set? Milestone must be set but check might be missing; do not let the green checkmark fool you. [ ] At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate label(s) before merge.


IndexError: tuple index out of range in identifyformat (io.registry) <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --Cron tests in HENDRICS using identifyformat have started failing in (e.g. ) with this error: As per a Slack conversation with and this should be related to Citing When is a string without a FITS extension, the function was returning None, now it executes <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks ( In [1]: from import identifyformat In [3]: from import Table In [4]: identifyformat("write", Table, "", None, [], {}) IndexError Traceback (most recent call last) Cell In [4], line 1 ----1 identifyformat("write", Table, "", None, [], {}) File ~/opt/anaconda3/envs/py310/lib/python3.10/site-, in makeiofunc.<locals.wrapper(registry, args, kwargs) 50 registry = defaultregistry 51 # get and call bound method from registry instance ---52 return getattr(registry, methodname)(args, kwargs) File ~/opt/anaconda3/envs/py310/lib/python3.10/site-, in UnifiedIORegistryBase.identifyformat(self, origin, dataclassrequired, path, fileobj, args, kwargs) 311 for dataformat, dataclass in self.identifiers: 312 if self.isbestmatch(dataclassrequired, dataclass, self.identifiers): --313 if self.identifiers(dataformat, dataclass): 316 (dataformat) 318 return validformats File ~/opt/anaconda3/envs/py310/lib/python3.10/site-, in is_fits(origin, filepath, fileobj, args, kwargs) 68 if ().endswith( 69 (".fits", "", ".fit", "", ".fts", "") 70 ): 71 return True ---72 return isinstance(args[0], (HDUList, TableHDU, BinTableHDU, GroupsHDU)) IndexError: tuple index out of range <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --


Table format assumes QDP commands are upper case assumes that commands in a QDP file are upper case, for example, for errors they must be "READ SERR 1 2" whereas QDP itself is not case sensitive and case use "read serr 1 2". As many QDP files are created by hand, the expectation that all commands be all-caps should be removed. The following qdp file should read into a with errors, rather than crashing. Create a QDP file: Running "qdp " works just fine. Python 3.10.9 (main, Dec 7 2022, 02:03:23) [Clang 13.0.0 (clang-1300.0.29.30)] astropy 5.1 Numpy 1.24.1 pyerfa 2.0.0.1 Scipy 1.10.0 Matplotlib 3.6.3


Incorrect units read from MRT (CDS format) files with When reading MRT files (formatted according to the CDS standard which is also the format recommended by AAS/ApJ) with , incorrectly parses composite units. According to CDS standard the units should be SI without spaces (http://vizier.u-). Thus a unit of (surface brightness for a continuum measurement) should be written as . When I use these types of composite units with the reader the units do not come out correct. Specifically the order of the division seems to be jumbled. The units in the resulting Table should be the same as in the input MRT file. Get astropy package from pip Using the following MRT as input: And then reading the table I get: For the SBCONT column the second is in the wrong place, and for SBLINE kpc2 is in the wrong place.


Add ` Or at least use the maximum precision of the matrix dtype instead of the arbitrarily chosen 1e-15.


Space between value and unit Currently, ` doesn't include a space between the value and unit: I think there are cases where it would make sense to allow a space to be included, so this is a feature request to add a boolean keyword argument to optionally add a space. Note that Quantity does include a space by default so maybe actually we should just change the default and not add an option?


Unicode and console unit representations sometimes include an extraneous space As noted in , for units typset in or format, a space is included in front, unlike for regular units, yet it is sometimes omitted if a unit scale factor is present. should never start with a space, independent of . From and Any astropy really.


Regarding FITS standard definition for 'Jy/beam' Astropy unit definition for Jy/beam currently exports it as 'beam-1 Jy' 'beam-1 Jy' This is contrary to how most radio astronomy packages define the unit. 'Jy/beam' seems to be the accepted convention. The space after beam-1 makes parsing needlessly cumbersome as well. Is this something that can be fixed? See related issues opened in SpectralCube and SoFiA2.


New Quantity warning starting with yesterday's numpy-dev Starting today, CI tests with and started failing due a new warning. I've extracted a MWE showing the warning: The warning is: The warning is not emitted with and stable (1.24.2). CC:


may use a string representation of floats that is larger than necessary In some scenarios, may use a string representation of floats that is larger than necessary, which can force comments to be truncated. Due to this, there are some keyword/value/comment combinations that are impossible to create via even though they are entirely possible in FITS. Being able to create any valid FITS Card via . contains the following card in the header: We can read the header of this file and get this card without any issue: However, we have problems creating a object with exactly the same contents of : Essentially the value "0." is being unnecessarily expanded to "0.", which forces the comment to be truncated. I've investigated the source code and the root issue is the function which creates a of when is used as the input: It seems to me that before doing , we should attempt to use the string representation provided by Python (in other words ), and we should only attempt to format it ourselves if the resulting string does not fit in 20 characters. However, since this is fairly deep in the code, it's possible this would have side-effects that I am not aware of. Windows-10-10.0.-SP0 Python 3.10.10 (tags/v3.10.10:, Feb 7 2023, 17:20:36) [MSC v.1929 64 bit (AMD64)] astropy 5.2.1 Numpy 1.24.2 pyerfa 2.0.0.1 Scipy 1.10.0 Matplotlib 3.6.3


creates a corrupt FITS files if a contains zero-dimensional data accepts a ndarray with shape (zero-dimensional) as a data array. This later causes issues when writing to a file because assumes that the data has at least 1 dimension, resulting in a corrupt FITS file. should never silently create a corrupt FITS file. Minimal reproducible example: Although this causes no errors/warnings, the resulting file is not valid FITS and will fail to properly open with . Windows-10-10.0.-SP0 Python 3.10.10 (tags/v3.10.10:, Feb 7 2023, 17:20:36) [MSC v.1929 64 bit (AMD64)] astropy 5.2.1 Numpy 1.24.2 pyerfa 2.0.0.1 Scipy 1.10.0 Matplotlib 3.6.3


may sometimes report differences between identical files In some scenarios, may report differences between identical files, even when comparing the same file to itself. This may be caused by improper handling of VLAs (variable-length arrays). only reports differences in files if they exist. Comparing a file to itself should never yield a difference. Prints out: I suspect the handling of VLAs is the culprit here as I couldn't reproduce the bug without using at least one VLA column. Windows-10-10.0.-SP0 Python 3.10.10 (tags/v3.10.10:, Feb 7 2023, 17:20:36) [MSC v.1929 64 bit (AMD64)] astropy 5.2.1 Numpy 1.24.2 pyerfa 2.0.0.1 Scipy 1.10.0 Matplotlib 3.6.3


Problem with "decimalyear" applied to MaskedColumn type The "decimalyear" type produces odd errors when applied to the MaskedColumn type. The "jyear" type does not, and appears to behave properly. I would expect "decimalyear" and "jyear" to work similarly, although the difference between them is not clear from the documentation. Linux-5.19.0-35-generic-x86_64-with-glibc2.35 Python 3.9.13 (main, Aug 25 2022, 23:26:10) [GCC 11.2.0] astropy 5.1


Writing a Table to FITS fails if the table contains objects The following works fine: whereas the following fails: with This behaviour is seen whenever a Table contains an object, i.e. does not know how to deal with . I wonder if we want the Table API to write objects to files by their string representation as a default, or otherwise provide a more meaningful error message?


TST: check fails with numpy-dev (TypeError: cannot write to unmasked output) Started popping up in numpy-dev jobs. is investigating.


Inconsistency in double single-quote ('') management in FITS Card The management of single-quotes in FITS cards seem correct, except sometimes when dealing with null strings, i.e. double single quotes (), which sometimes are transformed into single single quotes (). E.g.: gives If the null string is included in a larger value, the issue occurs at a different position: gives All card values should be handled properly. Linux-5.10.0-1029-oem-x86_64-with-glibc2.29 Python 3.8.10 (default, Mar 13 2023, 10:26:41) [GCC 9.4.0] astropy 5.2.1 Numpy 1.23.5 pyerfa 2.0.0 Scipy 1.10.0 Matplotlib 3.6.2


Make getting a topocentric ITRS position easier Right now, it is not easy to create ITRS coordinates for sources relative to a given location (rather than geocentric), to the level that we have specific instructions on how to calculate relative and then put these into an : This has led to numerous issues, the latest of which is It would be nice if as part of it would be possible to get a topocentric rather than a geocentric position. In , and (and below) to extend to take not just an but also a argument, with an implementation along : See . Labeling this a good first issue since it is easy code wise. However, writing the tests and documentation will require understanding of how ITRS and the associated coordinate transformations work.


Register Cosmology can now read and write to files. It would be nice to register with a method for exporting a Cosmology to a Latex table. There are good examples of IO with Cosmology at and documentation at I'm thinking the H0(..., format='latex')`.


BUG: change representation of vs table.Table More often than not it's rather confusing (and annoying) that a VOTable and a Table look exactly the same, but obviously, they don't behave the same way and don't have the same methods available, etc. I would suggest to change the votable case of to something else, e.g. .


TST: testtablegroupby[True] and testgroupbymasked[True] failed with numpy 1.25rc1 I see this in the predeps job that pulls in numpy 1.25rc1. Example log: Hard to discern between the other 100+ failures from and I do not understand why we didn't catch this earlier in devdeps. , does this look familiar to you? TST: testtablegroupby[True] and testgroupbymasked[True] failed with numpy 1.25rc1 I see this in the predeps job that pulls in numpy 1.25rc1. Example log: Hard to discern between the other 100+ failures from and I do not understand why we didn't catch this earlier in devdeps. , does this look familiar to you?


Add registration label ‘’ to Cosmology IO The Cosmology write methods that leverage Table should have the same keys. Table has both “latex” and “”, so too should Cosmology. Register the method a second time, under No response


QTable: Group keys don't have a unit When grouping a QTable with a column that contains a quantity, the keys only contain a float with a value, but not the full quantity: The keys should be complete, i.e. for a quantity column it should be a quantity with the proper unit. No response Linux-6.1.0-9-amd64-x86_64-with-glibc2.36 (Debian bookworm) Python 3.11.4 (main, Jun 7 2023, 10:13:09) [GCC 12.2.0] astropy 5.2.1 (also checked with 5.3) Numpy 1.24.2 pyerfa 2.0.0.3 Scipy 1.10.1 Matplotlib 3.6.3


Error in distance calculations for w0wz Cosmologies I believe that the equation used to calculate the dedensityscale in is incorrect. Line 205 has After manually calculating the integral/checking wolfram, I don't think it should be a negative in the exponent and should read: package from '...' run '...' error occurs. import platform; print(platform.platform()) import sys; print("Python", sys.version) import astropy; print("astropy", astropy.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version)


In v5.3, NDDataRef mask propagation fails when one of the operand does not have a mask This applies to v5.3. It looks like when one of the operand does not have a mask, the mask propagation when doing arithmetic, in particular with fails. This is not a problem in v5.2. I don't know enough about how all that works, but it seems from the error that the operand without a mask is set as a mask of None's and then the bitwise_or tries to operate on an integer and a None and fails. When one of the operand does not have mask, the mask that exists should just be copied over to the output. Or whatever was done in that situation in v5.2 where there's no problem. This is with v5.3. With v5.2, there are no errors. import sys; print("Python", sys.version) Python 3.10.11 (main, May 10 2023, 19:07:22) [Clang 14.0.6 ] import astropy; print("astropy", astropy.version) astropy 5.3 import numpy; print("Numpy", numpy.version) Numpy 1.24.3 import erfa; print("pyerfa", erfa.version) pyerfa 2.0.0.3 import scipy; print("Scipy", scipy.version) Scipy 1.10.1 import matplotlib; print("Matplotlib", matplotlib.version) Matplotlib 3.7.1


Possible bug in related to D exponents I came across the following code in : I think this may be incorrect because as far as I can tell (it returns a copy). Commenting out this code doesn't cause any tests to fail so I think this code isn't being tested anyway.


Context manager for constant versions For some use cases it would be helpful to have a context manager to set the version set of the constants. E.g., something like `


InheritDocstrings metaclass doesn't work for properties Inside the InheritDocstrings metaclass it uses which returns for properties.


units.quantityinput decorator fails for constructors with type hinted return value -None I am using the decorator with typing hints for constructors, however when I add the correct return value for the constructor () then I get an exception, because has no attribute . The issue can be reproduced with the following file: which results in the following error: This has been tested on Fedora 27 with python 3.6.3, astropy 2.0.2 and numpy 1.13.3 all from Fedora's repository. The issue can be circumvented by not adding the return type typing hint. Unfortunately, then a static type checker cannot infer that this function returns nothing. Maybe the decorator could explicitly check whether None is returned and then omit the unit check.


should support conversion to Because of the inheritance has a method which is useless. It should have a method which returns a object or objects. Conversion to (for ) and (for ) would also be great.


minversion failures The change in PR causes to fail in certain cases, e.g.: apparently because of a bug in LooseVersion (): Note that without the ".3" it doesn't fail: and using pkgresources.parseversion (which was removed) works: CC:


biweightlocation of a constant array returns nan Currently the robust mean estimator returns for an array with zero variance. eg: This is primarily because of a 0/0 division in the code (case when the calculated mad of array in denominator becomes zero). Wouldn't it be better to catch this special case and return the median, instead of returning nan?


Issue when passing empty lists/arrays to WCS transformations The following should not fail but instead should return empty lists/arrays:


Issue when transforming a single scalar coordinate with a 1D WCS The following example illustrates a bug when dealing with single scalar coordinates in 1D WCSes: - would you have a chance to look at this?


Record data size in the WCS object It is clear that there are practical reasons to have a record of the original data size in the WCS object. This in the past has been recorded in public attributes and and subsequently in the private and . There's along thread on why this should or should not be done in . More recently expanded this attribute to more than 2 axes. It also broke the ability to set the private attributes which was subsequently fixed in as a stop gap measure. We need to fix this permanently starting with v 1.3. There are two proposed ways to do it. public attributes, populated by the FITS header keywords. a subclass of which adds those and leave the original WCS to represent strictly the FITS WCS standard and nothing more. Either way a deprecation process will accompany the change. The purpose of this issue is to collect votes. I don't want to start a new long discussion. Keep in mind that is available for reference and only share new arguments. Since 1.3 is approaching we need to make a fast decision. So please share your preference here and volunteer for the work if possible.


Cosmologies used in equivalencies The thermodynamic temperature equivalency appears to default to the Planck 2015 cosmology value: whereas in the equivalency in , the default cosmology is used: and this is currently WMAP9. This seems inconsistent, so can we try and make things more consistent for the 3.1 release? (I see this as bug-like, so I think it can be addressed after feature freeze). Note that this is related to - if we change the default cosmology to Planck 2015, then we can change the equivalency to use the default cosmology without changing results (for now).


FITS-standard unit parsing fails on some types of exponents Why don't these work: When these all do: The non-working versions give e.g.: which is not how I would interpret the . Tested on 2.0.7 and 3.0.3


units: 's / m' and 's / m' are not convertible To paraphrase from , exceptions like (and a few other cases with first, second and third powers of second over meter, curiously) started popping up in our travis tests as seen at https://travis- . For a brief overview, running and getting into : I've managed to figure out that this is localized to 3.1. As suggested by on slack, I ran with and I was able to identify the first bad commit as I'm currently trying to find out the exact cause of this bug in that commit, but I figured it's best to submit this issue here before I accidentally close this tab or something.


Problem with the part of unit equivalencies? In the newly equivalencies: We notice that the implementation of seems to be wrong, as highlighted in the following figure: ! If , and , should it be equivalent to 140 Mpc, instead of 70Mpc? I can reproduce this so it is not a typo...


ncpprior referenced before assignment in Bayesian Blocks There is a bug in the bayesian blocks algorithm of It's not a big deal so I show you below how to solve it directly. When I call: I get: You can fix this just by changing: adding an else sentence EDIT: Text formatting ncpprior referenced before assignment in Bayesian Blocks There is a bug in the bayesian blocks algorithm of It's not a big deal so I show you below how to solve it directly. When I call: I get: You can fix this just by changing: adding an else sentence EDIT: Text formatting


Adding/subtracting ABmag Quantities loses the "type" of magnitude The following code raises a , because it appears the math operation lost track of the "type" of magnitude. and are both , so I would expect their difference to also be an ABmag. prints the following, and then raises: If the is changed to , the exception is different:


Header.fromstring does not accept Python 3 bytes According to , the method "...creates an HDU header from a byte string containing the entire header data." By "byte string" here it really means the type which on Python 2 could be raw binary data, but on Python 3 explicitly is not. In fact it does work on Python 3's unicode s, but here it assumes that the data can be ASCII-encoded. Its counterpart, will work with files opened in text or binary mode. So probably the simplest solution for now (as opposed to adding new methods or something like that) is to change to accept unicode or bytes string types. likely needs a similar treatment.


Support new clip ufunc Starting with numpy 1.17, will be based on a , which means we can ensure it works properly with . (Until we do so, we might also get failures.)


float16 quantities get upgraded to float64 automatically When trying to create a from a (not something I actually intended to do, I was experimenting while investigating other issue) it gets upgraded automatically to , which is something that does not happen with other float types: However: Somewhat related:


Misleading sqlmigrate "App 'apps.somethings' does not have migrations." error message Description This ticket is very similar to As shown above, validation should be sqlmigrate.


Make URLValidator reject invalid characters in the username and password Description (last modified by Tim Bell) Since , core.validators.URLValidator accepts URLs with usernames and passwords. RFC 1738 section 3.1 requires "Within the user and password field, any ":", " or "/" must be encoded"; however, those characters are currently accepted without being %-encoded. That allows certain invalid URLs to pass validation incorrectly. (The issue originates in Diego Perini's gist, from which the implementation in was derived.) An example URL that should be invalid is ; furthermore, many of the test cases in would be rendered valid under the current implementation by appending a query string of the form to them. I note Tim Graham's concern about adding complexity to the validation regex. However, I take the opposite position to Danilo Bargen about invalid URL edge cases: it's not fine if invalid URLs (even so-called "edge cases") are accepted when the regex could be fixed simply to reject them correctly. I also note that a URL of the form above was encountered in a production setting, so that this is a genuine use case, not merely an academic exercise. Pull request:  Make URLValidator reject invalid characters in the username and password Description (last modified by Tim Bell) Since , core.validators.URLValidator accepts URLs with usernames and passwords. RFC 1738 section 3.1 requires "Within the user and password field, any ":", " or "/" must be encoded"; however, those characters are currently accepted without being %-encoded. That allows certain invalid URLs to pass validation incorrectly. (The issue originates in Diego Perini's gist, from which the implementation in was derived.) An example URL that should be invalid is ; furthermore, many of the test cases in would be rendered valid under the current implementation by appending a query string of the form to them. I note Tim Graham's concern about adding complexity to the validation regex. However, I take the opposite position to Danilo Bargen about invalid URL edge cases: it's not fine if invalid URLs (even so-called "edge cases") are accepted when the regex could be fixed simply to reject them correctly. I also note that a URL of the form above was encountered in a production setting, so that this is a genuine use case, not merely an academic exercise. Pull request:


Add an option to django-admin to always colorize output Description With Django management commands, it is currently possible disable colors with the --no-colors flag. What I'd like to have is basically the other side of the coin: a --force-colors flag that instructs Django to output ANSI color sequences in cases it would disable colors by default (typically, when the output is piped to another command, as documented). My real world use-case is the following one: I have a custom Django command to import data. I run this command myself, and I'd like to send a colored log (HTML seems perfect for this) to the data curators. I can use the  utility for this, but that doesn't work since Django disable colors when the output is piped. Other *nix commands have a special flag for this exact use-case, for example $ ls --color=always


Add validation of related fields and lookups in model Meta.ordering Description When the ordering class member in Meta of a model contains a field from a related model, and that field does not exist, django's makemigrations does not throw an error. However, if it is a direct field member of the same class, makemigrations does throw an error. Example below tested on Django 2.0.5 from import models class Agreement(models.Model): agreementid = models.AutoField(verbosename='ID', serialize=False, autocreated=True, primarykey=True) #class Meta: # generates error in makemigrations # app.Agreement: (models.E015) 'ordering' refers to the nonexistent field 'id'. # ordering = ['id'] class Order(models.Model): agreement = models.ForeignKey(Agreement, models.DONOTHING) class Meta: # does not generate error in makemigrations # but does so during runtime # e.g. [x for x in ()] ordering = ['agreement_id']


diffsettings raises misleading exception message if using settings.configure() Description If, rather than using the env var DJANGOSETTINGSMODULE one uses settings.configure(...), attempting to call diffsettings can fail because it calls () unconditionally, with the exception Requested settings, but settings are not configured. You must either define the environment variable DJANGOSETTINGSMODULE or call settings.configure() before accessing settings. were the call instead: if not settings.configured: () things would work correctly.


Trunc() should allow passing isdst resolution to avoid NonExistentTimeError/AmbiguousTimeError Description (last modified by Alexander Holmbäck) When Trunc() truncates to a nonexisting or ambiguous datetime, the exception raised by pytz remains unhandled. The expected behavior would, IMO, be to not check the validity of truncated dates. This test for example: import datetime import pytz from import Trunc from import TestCase from import timezone from .models import Log class TestTruncateToInvalidTime(TestCase): def testtruncatetodstendsstockholm(self): tzinfo = pytz.timezone('Europe/Stockholm') timestamp = datetime.datetime(2018, 10, 28, 2, tzinfo=tzinfo) (timestamp=timestamp) logs = Log.objects.annotate(day=Trunc('timestamp', 'hour')).all() timezone.activate(tzinfo) self.assertEqual(logs[0], 28) Results in the following error: ERROR: testtruncatetodstendsstockholm () Traceback (most recent call last): File "", line 47, in testtruncatetodstendsstockholm self.assertEqual(logs[0], 28) File "", line 303, in getitem qs.fetchall() File "", line 1190, in fetchall self.resultcache = list(self.iterableclass(self)) File "", line 64, in iter for row in compiler.resultsiter(results): File "", line 1013, in applyconverters value = converter(value, expression, connection) File "", line 225, in convertvalue value = timezone.makeaware(value, ) File "", line 270, in makeaware return timezone.localize(value, isdst=is_dst) File "/home/alex/.virtualenvs/djangodev/lib/python3.6/site-", line 363, in localize raise AmbiguousTimeError(dt) pytz.exceptions.AmbiguousTimeError: 2018-10-28 02:00:00


Add app_label validation to showmigrations Description The app label validation was to some commands as above tickets. But showmigrations command doesn't contain it. So I think the validation should be to showmigrations command.


Models history doesn't use verbose names Description The history for a model object (within the admin section) should show human-readable messages, favoring verbose names over field names. However, this is not currently the case. For example, consider a model with the following class variable: pubdate = models.DateTimeField("date published") Changing the publication date for an object of that model, will display "Changed pubdate." in its admin history, rather than "Change date published." as one would expect (as older versions of Django did).


Union queryset with ordering breaks on ordering with derived querysets Description (last modified by Sergei Maertens) May be related to Simple reproduction (the exact models are not relevant I think): Dimension.objects.valueslist('id', flat=True) <QuerySet [10, 11, 12, 13, 14, 15, 16, 17, 18]qs = ( (pkin=[10, 11]) .union((pkin=[16, 17]) .orderby('order') ) qs <QuerySet [<Dimension: boeksoort, <Dimension: grootboek, <Dimension: kenteken, <Dimension: activa]qs.orderby().valueslist('pk', flat=True) <QuerySet [16, 11, 10, 17]qs [breaks] Traceback: Traceback (most recent call last): File "<input", line 1, in <moduleqs File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 248, in repr data = list(self[:REPROUTPUTSIZE + 1]) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 272, in iter self.fetchall() File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 1179, in fetchall self.resultcache = list(self.iterableclass(self)) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 53, in iter results = compiler.executesql(chunkedfetch=self.chunkedfetch, chunksize=self.chunksize) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 1068, in executesql cursor.execute(sql, params) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 100, in execute return super().execute(sql, params) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 68, in execute return self.executewithwrappers(sql, params, many=False, executor=self.execute) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 77, in executewithwrappers return executor(sql, params, many, context) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 85, in execute return (sql, params) File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 89, in exit raise djexcvalue.withtraceback(traceback) from excvalue File "/home/bbt/.virtualenvs/ispnext/lib/python3.6/site-", line 85, in execute return (sql, params) ORDER BY position 4 is not in select list LINE 1: ...dimensionsdimension"."id" IN (16, 17)) ORDER BY (4) ASC LIM... ^ Evaluating the qs instead of creating a new qs makes the code proceed as expected. [ for dim in qs]


Using RelatedOnlyFieldListFilter with reverse ManyToMany crashes Description (last modified by Tim Graham) Using RelatedOnlyFieldListFilter with a reverse ManyToMany relation causes this exception: getchoices() got an unexpected keyword argument 'limitchoicesto' This method in ForeignObjectRel.getchoices is missing the parameter that Field.get_choices has. Pull Request:  Demo of how to trigger bug: