This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ewosborne
Recipients christian.heimes, eric.smith, ewosborne, ncoghlan, serhiy.storchaka
Date 2018-02-14.15:00:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CA+97oKPoch2KhnNgmQ5==di6JNRX6SW0f73NHG_Ytn=SeVNv1g@mail.gmail.com>
In-reply-to <1518584162.51.0.467229070634.issue32820@psf.upfronthosting.co.za>
Content
Cool, I will kick it over to python-ideas.  I checked in some code to
handle the format string and it's a lot like what you're suggesting, so
I'll leave that in there and see what happens.
Thanks!

eric

On Tue, Feb 13, 2018 at 11:56 PM Nick Coghlan <report@bugs.python.org>
wrote:

>
> Nick Coghlan <ncoghlan@gmail.com> added the comment:
>
> Aye, definitely worth a thread on python-ideas. My rationale for
> suggesting something based on the built-in numeric codes is that it makes
> it straightforward for *users* to transfer knowledge from that
> mini-language.
>
> As far as parsing goes, I was thinking of something along the lines of the
> following naive approach:
>
>     typechar = fmt[-1:]
>     if not typechar or typechar not in ("b", "n", "x"):
>         return super().__format__(fmt)
>     prefix, group_sep, suffix = fmt[:-1].rpartition("_")
>     if prefix and prefix != "#" or suffix:
>         return super().__format__(fmt)
>     field_width = self._calculate_field_width(typechar)
>     return format(int(self),
> f"{prefix}0{field_width}{group_sep}{type_char}")
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue32820>
> _______________________________________
>
History
Date User Action Args
2018-02-14 15:00:52ewosbornesetrecipients: + ewosborne, ncoghlan, eric.smith, christian.heimes, serhiy.storchaka
2018-02-14 15:00:52ewosbornelinkissue32820 messages
2018-02-14 15:00:51ewosbornecreate