Bummer -- we can't sub-class NamedTuple

[portante]

This is not intended to be merged, but wanted others see the failed attempt.

I tried to create a PbenchNamedTuple with a __str__() method so that we can use that in multiple places, but the magic pixie dust doesn't cover this behavior.

See python/typing#427.

Ignore the first two commits, the last commit is the attempt.

[webbnh]

I don't have the brain-width to pursue this right now, but perhaps there is a solution using a "mix-in" or multiple inheritance?

[dbutenhof]

I don't have the brain-width to pursue this right now, but perhaps there is a solution using a "mix-in" or multiple inheritance?

Since that's basically what the NamedTuple does already, as I understood it, that might be possible; although the documentation I found seemed to convincingly dissuade readers from making the attempt... and the result might be uglier than we'd like. 😆

The basic idea of an introspective helper outside the class tree isn't entirely a bad one, all things considered ...

[webbnh]

As a alternative to NamedTuple, there's also @dataclass....

[dbutenhof]

As a alternative to NamedTuple, there's also @dataclass....

Well, that's interesting; and it basically already supports introspective stringification.

[webbnh]

True! It doesn't entirely solve the problem of attributes/fields which are objects (i.e., the whole point of the stringification effort was to make those display with deterministic values (i.e., ones which don't include reference addresses)), but it does offer a reasonable way to mark fields to be excluded from the repr() output, and it also allows the default __repr__() to be overridden.