Steve Jorgensen writes: > 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 "-∞".
Allowing objects to decide implicitly how to represent themselves is usually a bad idea, and we shouldn't encourage it. Yes, it's *very* cool that you can do things like "π = math.pi", and with MacroPy you can even do things like substitute "λ" for "lambda". However, if ways are provided to do this automatically depending on encodings and other variable environment state, people *will* put them into public libraries, and clients of those libraries will have to compensate for that. And of course there's the potential for foot-shooting in private libraries. If an application wants to make such substitutions, I have no objection to that. But "explicit is better than implicit", and those substitutions should be made at the level of application I/O, not the class level IMO. (Yes, I know those "levels" are ill-defined, but that's still an appropriate informal principle, I think.) > Prettiness awareness: > > It would be nice if an object could have control of how it is > represented when pretty-printed. In the stdlib pprint module, I see no way to do this. However, there is a private attribute _dispatch on PrettyPrinter which presumably could be augmented to "register" formatters for user-defined classes. > 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. Is that really enough, though? For example, presumably you want namedtuples to have their "items" printed like dict items, not like tuples. I haven't thought carefully about it, but ISTM that this would require a class-specific dunder able to extract the field names from the class and pair them with the values in the tuple, not just a start, end, component_list tuple. ISTM that if you want to do that, you could provide a private attribute that acts as flag to the __format__ method of a class that switches from the normal formatting to a "pretty" representation, and derive a PrettyPrinter class that internally sets and resets the flag. Ugly, I guess, but Should Work[tm]. Of course I'm speaking from my own preferences and experience, so WDYT? Yet another Steve :-) _______________________________________________ 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/632GBM36JXBXJ3UQY3REO6C4WQUVTE2U/ Code of Conduct: http://python.org/psf/codeofconduct/
