Right now:

>>> Formatter().parse("mira como bebebn los peces en el {rio} {de} {la} plata")
<formatteriterator object at 0x7f1fc7c7f150>
>>> next(_)
('mira como bebebn los peces en el ', 'rio', '', None)

This returned tuple should be a namedtuple, so it's self-explained for people exploring this (and usage of the fields become clearer)

I think this is all C coded, so it would entail making a new structseq object.

It's in string.py, so it would be easy just to add a namedtuple there:

class Formatter:
...
    def parse(self, format_string):
        return _string.formatter_parser(format_string)

I don't see a need to add a structseq to _string, since it's a private API.

collections is a moderately heavy module with many dependencies. string is a light module, it imports only _string. I'm -1 for using namedtuple in the string module.

I would also rather see string.py left light weight.  It would be better to change the upstream C code to use structseq.

I'm not convinced that a named tuple is needed here.

It does seem like overkill for something that's rarely used. I'm -0 on the structseq version.

IMHO this change makes things a bit more consistent. In lots of places when a tuple is returned, a `structseq` is used to improve readability on the returned result. Some examples of this are:

* grp.struct_group
* os.terminal_size
* pwd.struct_passwd
* resource.struct_rusage
* signal.struct_siginfo
* time.struct_time
* spwd.struct_spwd
* sys.float_info
* sys.int_info
* string.FormatterItem
* sys.hash_info
* sys.getwindowsversion
* sys.flags
* sys.version_info
* sys.thread_info

With the exception of string.FormatterItem, which is the change at hand.

It looks like Pablo's patch for this was good, but then closed because the idea was rejected.  Should this ticket also be closed as rejected?