You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I guess one could include the unicode stuff into the affected def_unit calls, but the bulk of the work is to smoke out all the affected units and add them in... Maybe @mhvk can advise.
Good suggestion! I think there are two separate issues here, one that the generic parser's unicode support for unit names is incomplete, and the other that there is no unicode parser, but only a unicode output format.
For the former, @maxnoe implemented quite a bit in #9348. As you can see, the reason you get some success is that the PR special-cases Ohm and Angstrom in
elifs[-1] =='\N{LATIN CAPITAL LETTER A WITH RING ABOVE}':
s=s[:-1] +'Angstrom'
I think we could add to that to solve the remaining ones - or perhaps be a bit cleverer and specifically compare with for possible unicode definitions of units.
For allowing format='unicode' in parsing, we need to change the present state, which is that 'unicode' is only an output format class (like 'latex'). I first thought it might be as simple as letting unicode format class inherit from the generic format class, but then realized it is trickier: e.g., composite units are typeset differently, so for proper round-tripping, the parser would need to be adjusted to enable parsing things like:
In [3]: u.Jy.decompose().to_string(format='unicode')
Out[3]: ' kg\n1×10⁻²⁶ ──\n s²'
In [4]: print(u.Jy.decompose().to_string(format='unicode'))
kg
1×10⁻²⁶ ──
s²
Do-able, of course, but perhaps not as worth it as just allowing the unit names to round-trip through generic...
The division in unicode is probably really too complicated to parse -- and I am also not sure if everybody expects this. For example, when building a table like the one above, it would destroy the table structure.
I would also not care too much about the unicode input specification -- however the error messages are a bit misleading then. This error message suggests that one can use unicode:
but then it also does not work.
For the acceptance of unicode characters at input: Maybe the simplest way would be to add the Unicodes as aliases directly to the def_unit() definitions?
Agreed, we should make clear that format='unicode' is not supported for parsing.
The one thing against just adding unicode to def_unit() is that then the symbol does become available as u.Ω as well - there was a specific decision in #9348 not to do that. That said, I guess one could keep them in the registry, separate from what is in the module.
Activity
pllim commentedon Jun 9, 2021
I guess one could include the unicode stuff into the affected
def_unitcalls, but the bulk of the work is to smoke out all the affected units and add them in... Maybe @mhvk can advise.olebole commentedon Jun 9, 2021
Finding them is simple:
This shows all unique but the prefixed units that raise the error:
Looks not overwhelming to me. Maybe I will have a look myself, if this is agreed to be useful..
pllim commentedon Jun 9, 2021
I don't see how it can hurt, though personally, I don't try to create a unit with unicode symbol. Let's see what @mhvk say first.
olebole commentedon Jun 9, 2021
I am still a bit unsure how it works there. For example, the unit "Ohm" is defined here:
astropy/astropy/units/si.py
Lines 180 to 182 in 6387507
This works well, i.e.
u.Unit(u.Ohm.to_string(format='unicode')) == u.OhmThe definition of the liter is quite similar:
astropy/astropy/units/si.py
Lines 45 to 47 in 6387507
but it raises the exception.
pllim commentedon Jun 9, 2021
I was thinking more like this:
pllim commentedon Jun 9, 2021
pllim commentedon Jun 9, 2021
Okay, sorry, what I did was this, not really what you asked for. Yeah, I am not sure how to get what you want...
mhvk commentedon Jun 9, 2021
Good suggestion! I think there are two separate issues here, one that the
genericparser's unicode support for unit names is incomplete, and the other that there is nounicodeparser, but only aunicodeoutput format.For the former, @maxnoe implemented quite a bit in #9348. As you can see, the reason you get some success is that the PR special-cases Ohm and Angstrom in
astropy/astropy/units/format/generic.py
Lines 452 to 458 in d6412f2
I think we could add to that to solve the remaining ones - or perhaps be a bit cleverer and specifically compare with for possible unicode definitions of units.
For allowing
format='unicode'in parsing, we need to change the present state, which is that 'unicode' is only an output format class (like 'latex'). I first thought it might be as simple as letting unicode format class inherit from the generic format class, but then realized it is trickier: e.g., composite units are typeset differently, so for proper round-tripping, the parser would need to be adjusted to enable parsing things like:Do-able, of course, but perhaps not as worth it as just allowing the unit names to round-trip through
generic...olebole commentedon Jun 9, 2021
The division in unicode is probably really too complicated to parse -- and I am also not sure if everybody expects this. For example, when building a table like the one above, it would destroy the table structure.
I would also not care too much about the
unicodeinput specification -- however the error messages are a bit misleading then. This error message suggests that one can use unicode:but then it also does not work.
For the acceptance of unicode characters at input: Maybe the simplest way would be to add the Unicodes as aliases directly to the
def_unit()definitions?mhvk commentedon Jun 9, 2021
Agreed, we should make clear that
format='unicode'is not supported for parsing.The one thing against just adding unicode to
def_unit()is that then the symbol does become available asu.Ωas well - there was a specific decision in #9348 not to do that. That said, I guess one could keep them in theregistry, separate from what is in the module.maxnoe commentedon Jun 9, 2021
@mhvk If I remember correctly, we said we could have a look again when we are python >= 3.7, which we are now, right?
maxnoe commentedon Jun 9, 2021
I think it was for module
__getattr__, like this:enables this:
mhvk commentedon Jun 9, 2021
OK, I made a fix to the parsing issue, see #11827.
For the parsing with 'unicode', it needs a better error message indeed, which I think is easier to deal with as a separate issue, so I raised #11828.
@maxnoe - indeed, you are right, we are now free to try to implement the module
__getattr__idea!