PrettyPrinter is invoked one object at a time

[shartse]

In the process of looking at turning stacks into a PrettyPrinter, I found that PrettyPrinter invokes the print function one object at a time:

for obj in objs:
    if type_canonical_name(obj.type_) != type_name:
        raise CommandError(
             self.name,
             f'exepected input of type {self.input_type}, but received '
             f'type {obj.type_}')
        self.pretty_print([obj])

This seems to be at odds with the signature of pretty_print, which is: pretty_print(self, objs: Iterable[drgn.Object]) and prevents writing a pretty_print function that takes into accounts all the objects being printed.

I tried out a code change that drops the error checking and calls self.pretty_print([obj]) directly and that seemed to work in simple cases, but I'm not sure if there is other command functionality built on the one-at-a-time processing. Assuming there's not, I need to figure out how to build error checking into a solution.

[ahrens]

I was wondering how that works, since some of the PrettyPrinters do process all their input at once (e.g. anything that prints a table with headers, like SplKmemCaches). All of these classes are hybrid Locator and PrettyPrinter. These classes don't invoke the code you quoted (which is from PrettyPrinter._call(). Instead they will use this code from Locator._call(), which seems to pass all the input objects at once:

    def _call(self,
              objs: Iterable[drgn.Object]) -> Optional[Iterable[drgn.Object]]:
        # pylint: disable=missing-docstring
        # If this is a hybrid locator/pretty printer, this is where that is
        # leveraged.
        if self.islast and isinstance(self, PrettyPrinter):
            # pylint: disable=no-member
            self.pretty_print(self.caller(objs))
        else:
            yield from self.caller(objs)

So I think it would be reasonable to change PrettyPrinter._call() to pass the entire input. As for verifying the input type, this isn't really specific to PrettyPrinter. We could move this checking to Command, and we could do it similarly to (or combined with) __invalid_memory_objects_check(). But I'd also be fine with simply removing this check for the time being.

[shartse]

Cool, thanks! Yeah - that all makes sense to me. I'm realizing that I may actually want to do a hybrid Locator/PrettyPrinter after all for stacks, but I'll still plan on opening a PR for this issue - I think it's worth it to standardize the PrettyPrinter behavior as much as possible.