I would love a formalized, for example, __pretty__ hook. Many of our
classes have __pretty__ and __json__ "custom" dunders defined and our
PrettyPrinters / JSONEncoders have checks for them (though the __pretty__
API has proven difficult to stabilize).
w/r/t to repurposing __str__, I (personally) think that's a nonstarter for
all the reasons listed but also because you may want to, for example,
insert line breaks in a long string in order to keep the output within some
width requirement. IMO, str.__str__("x" * 1000) should never even consider
doing that, but str.__pretty__("x" * 1000, pprinter_ref) might.
Jim Edwards
On Sun, Mar 15, 2020 at 11:44 AM Guido van Rossum <gu...@python.org> wrote:
> I think the idea you're looking for is an alternative for the pprint
> module that allows classes to have formatting hooks that get passed in some
> additional information (or perhaps a PrettyPrinter object) that can affect
> the formatting.
>
> This would seem to be an ideal thing to try to design and put on PyPI,
> *except* it would be more effective if there was a standard, rather than
> several competing such modules, with different APIs for the formatting
> hooks.
>
> So I encourage having a discussion (might as well be here) about the
> design of the new PrettyPrinter API.
>
> On Sun, Mar 15, 2020 at 4:08 AM Steve Jorgensen <ste...@stevej.name>
> wrote:
>
>> This is really an idea for an idea. I'm not sure what the ideal dunder
>> method names or APIs should be.
>>
>>
>> Encoding awareness:
>>
>> The informal (`str`) representations of `inf` and `-inf` are "inf" and
>> "-inf", and that seems appropriate as a known-safe value, but if we're
>> writing the representation to a stream, and the stream has a Unicode
>> encoding, then those might prefer to represent themselves as "∞" and "-∞".
>> If there were a dunder method for informal representation to which the
>> destination stream was passed, then the object could decide how to
>> represent itself based on the properties of the stream.
>>
>>
>> Prettiness awareness:
>>
>> It would be nice if an object could have control of how it is represented
>> when pretty-printed. If there is any way for that to be done now, it is not
>> at all evident from the pprint module documentation. It would be nice if
>> there were some method that, if implemented for the object, would be used
>> to allow the object to tell the pretty printer to treat it is a composite
>> with starting text, component objects, and ending text.
>>
>>
>> Additional thoughts & open questions:
>>
>> Perhaps there should only be stream awareness for informal representation
>> and prettiness awareness for formal representation (separate concepts and
>> APIs) or perhaps both ideas are applicable to both kinds of representation.
>>
>> Is it better for a stream-aware representation method to return the value
>> to be written to the stream or to directly append its representation to
>> that stream?
>> _______________________________________________
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/OQPPJ7SNM5CZUI5RYT5R4Z6YZWMNNTZS/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/3EF6W7DDSWRUAW57CFBTIUMANEH3P4TX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NX7NCTMPBROQXMCCDFIWACOO45QQVZLR/
Code of Conduct: http://python.org/psf/codeofconduct/
