UnicodeEncodeError using astropy.units.cds #5350
Comments
|
If this helps, the two unicode characters in question are: Using |
|
On python3 the first example works fine and I get a different failure with the second example: |
|
When >>> import astropy
>>> from astropy import coordinates as coord
>>> from astropy.units import cds
>>> astropy.__version__
'1.3.dev16038'
>>> coord.Angle('5d') # Without CDS
<Angle 5.0 deg>
>>> cds.enable()
<astropy.units.core._UnitContext at ...>
>>> coord.Angle('5deg')
<Angle 5.0 deg>
>>> coord.Angle('5°')
<Angle 5.0 deg>This is due to the following mapping in mapping = [
...
(['d'], u.d, "Julian day", ['c']),
((['deg', '°'], ['degree']), u.degree, "degree"),
...
] |
|
For Python 2, you need to import >>> from astropy import coordinates as coord
>>> from astropy.units import cds
>>> coord.Angle('5°') # Without unicode_literals
ValueError: 'ascii' codec can't decode ...
>>> from __future__ import unicode_literals
>>> coord.Angle('5°')
<Angle 5.0 deg>As for >>> from astropy.units import cds
>>> print(cds.__doc__)Hope this helps. |
|
I don't think the problem I originally reported is related to "d" being interpreted as Julian Day, at least when using Python 2.7 (it may explain the key error on Python 3). The following code also demonstrates the problem on Python 2.7 (and importing unicode_literals makes no difference): This is a serious bug that prevents us from using astropy.coordinates.Angle (unless we forbid our users from using astropy.units.cds). |
|
@r-owen , I cannot reproduce your error using the latest dev version. If this was indeed a bug, perhaps it is already fixed. Can you please try using Astropy dev and see if it works for you? >>> from __future__ import unicode_literals
>>> import astropy
>>> astropy.__version__
u'1.3.dev16118'
>>> from astropy import coordinates as coord
>>> from astropy import units as u
>>> from astropy.units import cds
>>> coord.Angle(5, unit=u.deg)
<Angle 5.0 deg>
>>> coord.Angle("5", unit=u.deg)
<Angle 5.0 deg>
>>> cds.enable()
<astropy.units.core._UnitContext at ...>
>>> coord.Angle(5, unit=u.deg)
<Angle 5.0 deg>
>>> coord.Angle("5", unit=u.deg)
<Angle 5.0 deg> |
|
I would like to understand why I can understand why |
|
Very weird bug. Definitely an issue on 1.2.1, so if this is indeed fixed (I cannot easily test...), we need to be sure it gets backported to 1.0.11 and 1.2.2. And without doing that: @pllim - did you try the exact same thing as posted by @r-owen? |
|
OK, from the trace, it is down to |
|
My fix is in #5355. Note that it does not fix the |
|
Thank you very much @mhvk! As to the issue with |
|
On Python 3, I get the The relevant code is: @classmethod
def _get_simple_unit_names(cls):
simple_units = set(
u.radian.find_equivalent_units(include_prefix_units=True))
simple_units.remove(u.deg)
simple_units.remove(u.hourangle)
simple_unit_names = set()
for unit in simple_units:
simple_unit_names.update(unit.names)
return list(simple_unit_names)which suggests that |
|
It definitely is a tricky bug, since I think the reason @pllim didn't see it is that some caching takes place when equivalent units are first searched for, and the code itself basically worked; it was just the test with |
|
|
@mhvk I had a quick look and caching is the problem there because the |
|
However an easy fix for the But this won't fix the caching issue. But if you like I can submit this workaround as PR. |
|
That would work. But I'm a bit confused because if you look at the output I show above, the CDS list does include a |
|
@timj That's because |
|
Hmm, just goes to show that I should write regression tests that exactly reproduce the problem reported! We'll indeed need to look into that code a bit deeper to see what exactly should be removed (my guess is the cds version of |
|
Should this issue be reopened because of the caching-issue in angleparser/the duplicate |
|
Yes, I hadn't realised that writing "partially fixes #" in comment would actually close something. Definitely not done yet! |
|
Thanks. I was wondering. I suppose you could file a new ticket for what remains broken (I admit I'm not sure what's fixed and what's broken at this point). |
|
@r-owen - it is the problem in python3 noted in #5350 (comment) |
|
Closing since #5483 is merged. Thanks all for helping to track these odd issues down! |
The following two scripts fail for me at the Python 2.7.12 command line using AstroPy 1.2.1:
and
The former fails with:
and the latter fails with:
See also https://groups.google.com/forum/#!topic/astropy-dev/-ebCdowI_0M
The text was updated successfully, but these errors were encountered: