Skip to content
This repository was archived by the owner on May 26, 2022. It is now read-only.

Proposal to add an Angle format specifier to Angle.to_string()#11

Closed
taldcroft wants to merge 4 commits into
astropy:masterfrom
taldcroft:patch-1
Closed

Proposal to add an Angle format specifier to Angle.to_string()#11
taldcroft wants to merge 4 commits into
astropy:masterfrom
taldcroft:patch-1

Conversation

@taldcroft

Copy link
Copy Markdown
Member

No description provided.

Comment thread angle_format.rst

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copied from astropy-dev e-mail:
This wording is somewhat confusing; perhaps change to:
"%DM Minute component in units of arcminutes (fraction of a degree)"
or something similar

@mhvk

mhvk commented Aug 24, 2013

Copy link
Copy Markdown

@taldcroft - I'll ask a more general question on whether this is the right approach on astropy-dev, but since this certainly is very neat, here some comments more specific to your suggestion (in order, though none essential):

  1. For number-of-digits, I'd suggest following the de-facto standard, e.g., %<length.#ofdigitsafterpoint>DD. Not fond at all of using number of additional d's as in the %DD.ddd example (really uncomfortable if one wants >5 digits, which is not that unrealistic). Effectively, of course, this means the format becomes rather like that of int/float (depending on whether #ofdigitsafterpoint is mentioned), with the letter(s) indicating what is being formatted.
  2. Related, I'd hide the %+ option in the above (again following standards); e.g., %+5.2DD.
  3. Also related, what is the default # of digits? For most, 2 would be right, but degrees can have 3. Perhaps particularly relevant for %HMS and %DMS.
  4. Why caps rather than lower case? To avoid confusion?
  5. I'm not in favour of any additional unit stuff, as this is possible already with standard python formatting (e.g., "{:10.5f}".format(a.to(u.mas).value))

@taldcroft

Copy link
Copy Markdown
Member Author

@mhvk - thanks for the feedback.

  1. Something like that occurred to me and was a close second to the DD.ddd idea. I would be fine with your de-facto standard idea. In fact it does sound better now since it also allows solving the fixed vs. non-fixed width issue nicely.
  2. I didn't remember the %+5.2 syntax. Even better!
  3. Not sure what should be the default, but with this syntax it can be configured quite easily.
  4. I started with caps just because I was thinking of HH:MM:SS.sss which I sometimes write for times. But I was pretty close to updating the proposal to use lower case directives when I had to leave the keyboard. So I'm on board with lower case as well if it ends up looking more clear.
  5. I see your point here. This might need iteration but is second-order for now.

It might be worth noting that part of my madness is a desire to have the Angle object be fully aware of how to output itself via configurable object properties, not just keywords in a specialized output method. You've seen this idea in Time. I want code like this to work:

>>> t = Table()
>>> a = Angle([1, 2], unit=u.deg)
>>> t['a'] = a
>>> print t
a
deg
---
1
2
>>> t['a'].format = '%dms'
>>> t['a'].precision = 5
>>> t['a'].style = 'colons'  # Maybe "colon-sep" ?
>>> print t
a
deg
---------------
1:00:00.00000s
2:00:00.00000s

>>> t['b'] = t['a'] + 10 * u.deg
>>> print t
a               b
deg             deg
--------------- ----------------
1:00:00.00000s  11:00:00.00000s
2:00:00.00000s  12:00:00.00000s

@taldcroft taldcroft closed this Jul 11, 2018
@taldcroft taldcroft deleted the patch-1 branch July 11, 2018 12:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants