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