Steven D'Aprano wrote: > Eric Smith wrote: >> Terry Reedy wrote: >>> Ron Adam wrote: >>>> >>>> >>>> Steven D'Aprano wrote: >>>>> Michael Foord wrote: >>>>> >>>>>> Don't we have a pretty-print API - and isn't it spelled __str__ ? >>>>> >>>>> Not really. If it were as simple as calling str(obj), there would >>>>> be no need for the pprint module. >>>> >>>> I agree. And when I want to use pprint, there are usually >>>> additional output formatting requirements I need that isn't a "one >>>> size fits all" type of problem. >> >> I don't see how you can have a standard interface (like __pprint__), >> and have additional, per-object formatting parameters. > > I don't see how you can't. Other standard methods take variable > arguments: __init__, __new__, __call__ come to mind. Those are different, since they're called on known specific objects. Having params to a generic __pprint__ method would be more like having params to __str__ or __repr__. If you know enough about the object to know which parameters to pass to its pretty-print function, then just call a normal method on the object to do the pprint'ing. But, for example, assuming pprint for a list is recursive (as it is for repr), how would you pass the arguments around? > > But that's beside the >> point, I don't like __pprint__ in any event. Too special. > > I'm not sure what you mean by "too special". It's no more special than > any other special method. Do you mean the use-case is not common enough? > I would find this useful. Whether enough people would find it useful > enough to add yet another special method is an open question. Bad choice of words on my part. I meant "too special case" for such machinery. That is, the use case isn't common enough.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4