Modify Formatter Class to handle arbitrary objects

[RossBiro]

BPO	36159
Nosy	@ericvsmith, @lisroach

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-03-01.18:00:37.406>
labels = ['type-feature', 'library', '3.10']
title = 'Modify Formatter Class to handle arbitrary objects'
updated_at = <Date 2020-11-24.15:34:57.335>
user = 'https://bugs.python.org/RossBiro'

bugs.python.org fields:

activity = <Date 2020-11-24.15:34:57.335>
actor = 'eric.smith'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-03-01.18:00:37.406>
creator = 'Ross Biro'
dependencies = []
files = []
hgrepos = []
issue_num = 36159
keywords = []
message_count = 4.0
messages = ['336945', '337715', '337738', '381751']
nosy_count = 3.0
nosy_names = ['eric.smith', 'lisroach', 'Ross Biro']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue36159'
versions = ['Python 3.10']

[RossBiro]

The only point in the string.Formatter class that really depends on string output is line 245: return ''.join(result), auto_arg_index.

I'm currently working on a problem that would be much easier if I could get access to the result list instead of having that join called.

I propose creating another overridable method in string.Formatter, say oformat that calls _vformat and is called by vformat. oformat would have the guts of vformat and just return the result list. vformat would then consist of the call ot oformat and the join. See Below. The recursive call to _vformat would also need some slight modification.

The work would not be difficult and I'm willing to do it, provided there is sufficient interest.

def vformat(self, format_string, args, kwargs):
        result = self.oformat(format_string, args, kwargs)
	return ''.join(result)

def oformat(self, format_string, args, kwargs):
        used_args = set()
        result, _ = self._vformat(format_string, args, kwargs, used_args, 2)
        self.check_unused_args(used_args, args, kwargs)
        return result

[lisroach]

Can you give an example use case for this? F-strings are the newer method of string interpolation, I'm not sure it's worth putting effort into adding features to string.Formatter.

[RossBiro]

I'm currently writing a language translator between two domain specific
computer languages. Because some expressions occur repeatedly, but in
slightly different contexts, I make multiple passes. The first pass
reduces everything it can and leaves place holder objects for things it
can't reduce. Later passes replace the objects with their final expression
in the new language. The final expression varies by context, so every time
it's reevaluated, it could change. I would really like to handle things
like a + b as

"{a} + {b}".format(a=a, b=b)

This works great when a and b are strings. But when they are place holder
objects, I wasn't able to find a good solution. Although the Formatter
class came so close that I thought I would suggest the change. What I
ended up doing was replacing objects with unique strings so that I could
use format and then using regular expressions on the output string to split
it into an array and replace the string identifiers with the original
objects. The change I've suggested to the Formatter class would have
allowed me to skip the regular expressions.

Ross

On Mon, Mar 11, 2019 at 11:47 PM Lisa Roach <report@bugs.python.org> wrote:

Lisa Roach <lisaroach14@gmail.com> added the comment:

Can you give an example use case for this? F-strings are the newer method
of string interpolation, I'm not sure it's worth putting effort into adding
features to string.Formatter.

----------
nosy: +lisroach

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue36159\>

---

--
*Ross Biro* | CTO

---

O: 240-380-2231| F: 240-556-0361 <(240)%20556-0361>
The Interface Financial Group <https://interfacefinancial.com/\>

CONFIDENTIALITY NOTICE: This email message, including any attachments, is
for the sole use of the intended recipient/s and may contain confidential &
privileged information. Any unauthorized review, use, disclosure, or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
messages and any attachments.

[ericvsmith]

I just stumbled across this. I don't think the idea is totally without merit, although maybe it's too niche to warrant being in the stdlib. It should probably be discussed on python-ideas first.

[ericvsmith]

I'm going to close this, although I still think the idea has some merit. If someone wants to pick it up, I think bringing it up on discuss.python.org is the next step.